Re: [GENERAL] cache lookup of relation 165058647 failed

[Renames thread from "The Pepsi Challenge" to "The PostgreSQL
Challenge"]

>> 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