Florian Weimer <fweimer@xxxxxx> writes: > This query: > SELECT 1 FROM information_schema.tables WHERE table_schema = $1 AND table_name = $2; > fails sporadically with the error "relation with OID <number> does not > exist". > I guess the OID refers to a temporary table because I can't find it in > pg_class, and the cause is a race between listing the tables and > applying the permission checks to them (which I don't need anyway, I > think) because tables in the system catalog are not subject to MVCC. Yeah, that's what I guess too. There is a change in 8.4 that should prevent this class of failures: 2008-12-15 13:09 tgl * src/: backend/catalog/namespace.c, backend/utils/adt/acl.c, test/regress/expected/privileges.out: Arrange for the pg_foo_is_visible and has_foo_privilege families of functions to return NULL, instead of erroring out, if the target object is specified by OID and we can't find that OID in the catalogs. Since these functions operate internally on SnapshotNow rules, there is a race condition when using them in user queries: the query's MVCC snapshot might "see" a catalog row that's already committed dead, leading to a failure when the inquiry function is applied. Returning NULL should generally provide more convenient behavior. This issue has been complained of before, and in particular we are now seeing it in the regression tests due to another recent patch. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
