Bruce, please make sure to keep the list copied on replies. I think there is an important bug here and I don't want it to get lost just because I lose track of it. I'm also crossposting to pgsql-hackers. Bruce McAlister wrote: > okidoki, I tried this: > > blueface-crm=# select relname, nspname from pg_class join pg_namespace > on (relnamespace = pg_namespace.oid) where > pg_is_other_temp_schema(relnamespace); > relname | nspname > ----------+------------ > temp4295 | pg_temp_63 > (1 row) > > blueface-crm=# select pg_stat_get_backend_pid(63); > pg_stat_get_backend_pid > ------------------------- > 6661 > (1 row) > > blueface-crm=# select datname, client_addr, client_port from > pg_stat_activity where procpid = '6661'; > datname | client_addr | client_port > ----------------+-------------+------------- > whitelabel-ibb | 10.6.0.181 | 1587 > (1 row) > > Is that correct? If it is then I'm really confused, how can a connection > to the whitelabel-ibb database create temporary tables in the > blueface-crm database? Well, it certainly seems like this shouldn't be happening. Maybe the table belonged to a session that crashed, but the pg_class entry has not been cleaned up -- possibly because that backend has not connected to that particular database. Maybe autovacuum itself could do something about cleaning up this kind of stuff on sight (--> dropping temp tables belonging to sessions that crash). I'm not sure though. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
