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.
with ReturnSetInfo->expectedDesc. This allows custom datatypes
(e.g. from tsearch2) to be returned at runtime. Previous behavior
depended on the type oid to match between the remote and local
database, which obviously doesn't work well for custom types.
Per report from Mark Gibson.
complete ExtendCLOG() before advancing nextXid, so that if that routine
fails, the next incoming transaction will try it again. Per trouble
report from Christopher Kings-Lynne.
incorrect permissions checking, but in fact disabled most all permissions
checks for view updates. This corrects problems reported by Sergey
Yatskevich among others, at the cost of re-introducing the problem
previously reported by Tim Burgess. However, since we'd lived with that
problem for quite awhile without knowing it, we can live with it awhile
longer until a proper fix can be made in 7.5.
This should prevent some obscure cases of 'variable not in subplan target
lists', although actual failures have only been reported against 7.4 in
which the bug is much easier to trigger.
rule split the query into one INSERT and one UPDATE where the UPDATE
then hit's the just created row without modifying the key fields again.
In this special case, the new key slipped in totally unchecked.
Jan
This is not 100% backward compatible as formerly a double quoted
type name containing a dot could be used. But I don't think may people
use dot's in the name of user defined types.
Jan
subquery that didn't previously have one. We have traditionally made
the caller of ResolveNew responsible for updating the hasSubLinks flag
of the outermost query, but this fails to account for hasSubLinks in
subqueries. Fix ResolveNew to handle this. We might later want to
change the calling convention of ResolveNew so that it can fix the
outer query too, simplifying callers. But I went with the localized
fix for now. Per bug report from J Smith, 20-Oct-03.
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
Hi There's a bug in the clusterdb script where it looks like the arguments
to the psql command are being passed in the wrong order, so it fails when
you run it on a database that is not on localhost.
Here's the output from the command:
133 anands-Computer:bin/scripts> clusterdb -h wooster -U rr granada
psql: warning: extra option wooster ignored
psql: warning: extra option -U ignored
psql: warning: extra option rr ignored
psql: warning: extra option -F: ignored
psql: warning: extra option -P ignored
psql: warning: extra option format=unaligned ignored
psql: warning: extra option -t ignored
psql: warning: extra option -c ignored
psql: warning: extra option SELECT nspname, pg_class.relname,
pg_class_2.relname FROM pg_class, pg_class AS pg_class_2 JOIN pg_namespace
ON (pg_namespace.oid=relnamespace), pg_index WHERE
pg_class.oid=pg_index.indrelid AND pg_class_2.oid=pg_index.indexrelid AND
pg_index.indisclustered AND pg_class.relowner=(SELECT usesysid FROM
pg_user WHERE usename=current_user) ignored
psql: FATAL: user "-h" does not exist
I'm attaching a patch that fixes the problem. The diff was run on
postgresql 7.3.4
Thanks a lot.
Anand Ranganathan
