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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
