But, I am suspecting that it's a race condition with the new background
writer code.
Why? Have you demonstrated that the failure does not occur in 7.4?
What other operations have been added to HEAD that would allow for successful operation of sequential use or testing of temp tables?
More importantly, yes, I can confirm that this behavior doesn't exist in REL7_4 as of 40min ago. I've been running the exact same tests repeatedly with nearly identical configs (as close as they can be given the config changes) on REL7_4 as I have HEAD and only HEAD is giving me problems.
psql:test-end2.sql:3: ERROR: cache lookup failed for relation 398033 CONTEXT: SQL query "SELECT TRUE FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = 'tmptbl'::TEXT AND c.relkind = 'r'::TEXT AND pg_catalog.pg_table_is_visible(c.oid)"
I think that pg_table_is_visible() will inspect the catalogs using
SnapshotNow semantics, while the above query will feed it with OIDs that
were valid under a start-of-query snapshot. So I'd expect failures in
any recent PG version, if tables are being dynamically created/deleted
by concurrent transactions.
There is no concurrency in the test I gave: it's all sequential.
0 | -- connect 1 | BEGIN; 2 | SELECT setuid_wrapper(); 3 | -- Do other things; 4 | COMMIT; 5 | -- disconnect 6 | -- connect again 7 | BEGIN; 8 | SELECT setuid_wrapper(); -- This fails some % of the time
If I add step 5.5 that is a sleep, step 8 will work, without fail. In 7.4, I have no problems, however. That said, the bgwriter code is the only think that I can think of that would muck with caching. -sc
PS Other comments temp schema permission patch?
-- Sean Chittenden
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
