Re: Restore enforce_generic_type_consistency's breaks a farms - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Restore enforce_generic_type_consistency's breaks a farms
Date
Msg-id 26055.1229348214@sss.pgh.pa.us
Whole thread Raw
In response to Restore enforce_generic_type_consistency's breaks a farms  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Restore enforce_generic_type_consistency's breaks a farms
List pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@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


pgsql-hackers by date:

Previous
From: Robert Lor
Date:
Subject: DTrace probes patch
Next
From: Tom Lane
Date:
Subject: Re: Function with defval returns error