Обсуждение: 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