Обсуждение: Restore enforce_generic_type_consistency's breaks a farms

Following commit:

http://archives.postgresql.org/pgsql-committers/2008-12/msg00109.php

breaks several farms. Is it know issue? I run test manually and it works.
    Zdenek

Details:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2008-12-14%2021:06:00

================== pgsql.24224/src/test/regress/regression.diffs ===================
*** 
/zfs_data/home/postgres/buildfarm/HEAD/pgsql.24224/src/test/regress/expected/polymorphism.out 
Sun Dec 14 22:06:23 2008
--- 
/zfs_data/home/postgres/buildfarm/HEAD/pgsql.24224/src/test/regress/results/polymorphism.out 
Sun Dec 14 22:34:09 2008
***************
*** 616,626 ****  -- check that we can apply functions taking ANYARRAY to pg_stats  select distinct
array_ndims(histogram_bounds)from pg_stats  where histogram_bounds is not null;
 
!  array_ndims
! -------------
!            1
! (1 row)
!  -- such functions must protect themselves if varying element type isn't OK  select max(histogram_bounds) from
pg_stats; ERROR:  cannot compare arrays of different element types
 
--- 616,622 ----  -- check that we can apply functions taking ANYARRAY to pg_stats  select distinct
array_ndims(histogram_bounds)from pg_stats  where histogram_bounds is not null;
 
! ERROR:  relation with OID 29632 does not exist  -- such functions must protect themselves if varying element type
isn'tOK  select max(histogram_bounds) from pg_stats;  ERROR:  cannot compare arrays of different element types
 

======================================================================

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

I wrote:
> ... 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.

On checking the archives, it seems most of the previous complaints have
been about "cache lookup failed" errors arising from pg_table_is_visible
and its ilk; those are used in the queries generated by psql's \d
commands.

So my proposal is to change the OID-accepting variants of
has_table_privilege and friends, as well as pg_table_is_visible and
friends, to silently return FALSE instead of failing when given a
bad OID.  I had originally thought we might change the underlying
functions (pg_class_aclcheck, RelationIsVisible, etc) but it looks
like it'd be better to expend a SearchSysCacheExists call in the
SQL-accessible functions.  (This doesn't leave a race condition
since there'd not be any check for syscache invalidation messages
between the SearchSysCacheExists and the ensuing lookup.)
        regards, tom lane

On Mon, Dec 15, 2008 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> ... 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.
>
> On checking the archives, it seems most of the previous complaints have
> been about "cache lookup failed" errors arising from pg_table_is_visible
> and its ilk; those are used in the queries generated by psql's \d
> commands.
>
> So my proposal is to change the OID-accepting variants of
> has_table_privilege and friends, as well as pg_table_is_visible and
> friends, to silently return FALSE instead of failing when given a
> bad OID.  I had originally thought we might change the underlying

Or maybe NULL?

...Robert

"Robert Haas" <robertmhaas@gmail.com> writes:
> On Mon, Dec 15, 2008 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So my proposal is to change the OID-accepting variants of
>> has_table_privilege and friends, as well as pg_table_is_visible and
>> friends, to silently return FALSE instead of failing when given a
>> bad OID.  I had originally thought we might change the underlying

> Or maybe NULL?

Hmm, yeah, that's not a bad idea.
        regards, tom lane