owned by postgres, doing "pg_ctl start" as root could allow a privilege
escalation attack, as pointed out by iDEFENSE. Of course the postmaster would
fail, but we ought to fail a little sooner to protect sysadmins unfamiliar
with Postgres. The chosen fix is to disable root use of pg_ctl in all cases,
just to be confident there are no other holes.
is called. getByte presents a can't happen situation as no function
can return a TINYINT because pg doesn't have an equivalent type.
Make this throw an exception if we get to this point.
Thanks to Christian Niles.
This seems the cleanest way of fixing its lack of a shutdown callback,
which was preventing it from working correctly in a query that didn't
run it to completion. Per bug report from Szima GÄbor.
was large enough to be batched and the tuples fell into a batch where
there were no inner tuples at all. Thanks to Xiaoyu Wang for finding a
test case that exposed this long-standing bug.
function to prevent multiple threads using automatic cursors on
the same connection from stomping over each others cursor.
Originally Jan Wieck, re-reported by Jack Orenstein after
accidental removal.
assuming it had been set instead of correctly calling the
isUpdateable() method which sets the flag if needed. This usually
worked because moveToCurrentRow is only useful after a
moveToInsertRow call which would set the flag, but this is not
required.
David Bucciarelli
value of 'start' could be past the end of the page, if the page was
split by some concurrent inserting process since we visited it. In
this situation the code could look at bogus entries and possibly find
a match (since after all those entries still contain what they had
before the split). This would lead to 'specified item offset is too large'
followed by 'PANIC: failed to add item to the page', as reported by Joe
Conway for scenarios involving heavy concurrent insertion activity.
for transaction commits that occurred just before the checkpoint. This is
an EXTREMELY serious bug --- kudos to Satoshi Okada for creating a
reproducible test case to prove its existence.
force relcache rebuild for the other table as well as the column's
own table. Otherwise, already-cached foreign key triggers will stop
working. Per example from Alexander Pravking.
This is required by SQL spec to avoid failures in cases like
SELECT sum(win)/sum(lose) FROM ... GROUP BY ... HAVING sum(lose) > 0;
AFAICT we have gotten this wrong since day one. Kudos to Holger Jakobs
for being the first to notice.
