Re: Restore enforce_generic_type_consistency's breaks a farms

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Restore enforce_generic_type_consistency's breaks a farms
Date: 2008-12-15 13:36:54
Message-ID: 26055.1229348214@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-15 13:43:00 Re: Function with defval returns error
Previous Message Heikki Linnakangas 2008-12-15 13:35:53 Re: Sync Rep: First Thoughts on Code