Zdenek Kotala <zdenek.kot...@sun.com> writes:
> Following commit:
> http://archives.postgresql.org/pgsql-committers/2008-12/msg00109.php
> breaks several farms. Is it know issue?
Hmm. What I think is happening is that sometimes there's a pg_statistic
entry for a table that another process is in the midst of dropping.
The has_table_privilege() call that's embedded in the pg_stats view
fails if the DROP has already committed, even though the catalog entries
are still visible to the caller's snapshot.
The easy workaround to this is to make the regression test reference
pg_statistic directly instead of pg_stats (okay because the tests
require superuser privilege anyway). But this type of problem has come
up before. I wonder if we shouldn't do what was previously discussed:
make has_table_privilege and related functions silently return FALSE,
instead of throwing error, when given a "nonexistent" OID.
I wouldn't suggest doing this in 8.3.x, so probably removing the new
regression test from 8.3.x is the way to fix that branch. It seems
like it might be a good thing to do in HEAD though. Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
