Re: [GENERAL] cache lookup of relation 165058647 failed

>>> temp tables don't use the shared buffer cache, how can this be
>>> related to the BG writer?
>> Don't the system catalogs use the shared buffer cache?
>> BEGIN;
>> SELECT create_temp_table_func();  -- Inserts a row into pg_class via
>> CREATE TEMP TABLE
>> -- Do other stuff
>> COMMIT;              -- After the commit, the row is now visible to other
>> backends
>> -- disconnect      -- If the delay between the disconnect and reconnect
>> is small enough
>> -- reconnect        -- It's as though there is a race condition that allows
>> the function
>>                 -- pg_table_is_visible() to assert the "cache lookup of relation"
>>                 -- error.
>> BEGIN;
>> SELECT create_temp_table_func();  -- Before the CREATE TEMP TABLE, I
>> call
>>                              /* SELECT TRUE FROM pg_catalog.pg_class c
>>                                 LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
>>                                 WHERE c.relname = ''footmp''::TEXT AND
>>                                 c.relkind = ''r''::TEXT AND
>>                                 pg_catalog.pg_table_is_visible(c.oid); */
>>                             -- But the query fails
>> My guess was that the series of events went something like:
>> proc 0) COMMIT's and the row in pg_class is committed
>> proc 1) bgwriter writer code removes a page for the cache
>> proc 2) queries for the page  [*]
>> proc 1) writes it to disk
>> proc 2) queries for the page  [*]
>> proc 1) sync's the fd
>> [*] proc 2 queries for the page at either of these points
>> In 7.4, there is no bgwriter or background process mucking with cache,
>
> Except for the checkpoint process, which does exactly the same as the
> bgwriter does, and ALL concurrent backends whenever they feel the need
> to evict a dirty buffer.

Hrm...  well, haven't the slightest idea what would be causing this
then.  About all I can say is that some problem does exist in HEAD that
doesn't exist in REL7_4 that I'm able to tickle via temp tables.  :-/
Because this is time sensitive, what debugging foo could I insert to
get some useful diagnostic output?

> If it makes a difference if a pg_class page is dirty in the buffer or
> copied out to disk with respect to visibility rules of the tuples
> contained in it, then the whole thing is a way larger bug than the one
> in MIB. First of all, committed or not, a temp object from one session
> should NEVER be visible in any other.

Hrm...  well, I'm going to take my test scripts and reduce them down to
a test case.  For sure, there's something different in HEAD that's
causing problems that are time sensitive.  I've even thought about
grabbing my camera and making a low res 320x200 movie of the test
sequence.  I went and ran script(1) on one of the runs for the sake of
something.

http://sean.chittenden.org/postgresql/pgsql-create-temp-bug-
typescript.txt

Any help or assistance is greatly appreciated, I'm not sure where to go
from here.  -sc

--
Sean Chittenden