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.
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.
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.
easily exhaust memory on databases with more than a few hundred triggers.
I don't expect any more releases of these old versions, but let's put the
fix in CVS just so it's archived.
bottom. Otherwise we fail to moveright when the root page was split while
we were "in flight" to it. This is not a significant problem when the root
is above the leaf level, but if the root was also a leaf (ie, a single-page
index just got split) we may return the wrong leaf page to the caller,
resulting in failure to find a key that is in fact present. Bug has existed
at least since 7.1, probably forever.
harmless on signed-char machines but would lead to core dump in the
deadlock detection code if char is unsigned. Amazingly, this bug has
been here since 7.1 and yet wasn't reported till now. Thanks to Robert
Bruccoleri for providing the opportunity to track it down.
known problem with failure to respond to 'pg_ctl stop -m fast', and
probable problems if SIGINT or SIGTERM arrives while processing a
SIGUSR2 interrupt that arrived while waiting for a new client query.
in ruleutils output. The previous partial parenthesization was a hack
to get around grammar restrictions that have since been fixed; and as
Sam O'Connor pointed out, there were cases where it didn't work.
Fixed bug with '=' operator for gist__int_ops and
define '=' operator for gist__intbig_ops opclass.
Now '=' operator is consistent with standard 'array' type.
Thanks Achilleus Mantzios for bug report and suggestion.
Oleg Bartunov