Re: Restore enforce_generic_type_consistency's breaks a farms
От | Tom Lane |
---|---|
Тема | Re: Restore enforce_generic_type_consistency's breaks a farms |
Дата | |
Msg-id | 26055.1229348214@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Restore enforce_generic_type_consistency's breaks a farms (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Ответы |
Re: Restore enforce_generic_type_consistency's breaks a farms
|
Список | 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 по дате отправления: