error conditions during regexp compile, but not during regexp execution;
any sort of "can't happen" errors would be treated as no-match instead
of being reported as they should be. Noticed while trying to duplicate
a reported Tcl bug.
Prevent a backend crash when processing CREATE TABLE commands with
more than 65K columns, or when the created table has more than 65K columns
due to adding inherited columns from parent relations. Fix a similar
crash when processing SELECT queries with more than 65K target list
entries. In all three cases we would eventually detect the error and
elog, but the check was being made too late.
that is of no concern to us --- it must belong to a different userid,
which means it is not a Postgres shmem segment (or at least,
not one that is relevant to our data directory). I plan a more extensive
fix in HEAD, but this is a simple change that prevents failure-to-reboot
problems for single-postmaster installations.
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.
