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