> OK, I have looked at the problem, and found a few things. First, if you
> look in data/base/dbname, you will see the actual temp files are not
> there. The only place they exist after psql exit is in pg_class.
>
> Second, I found that if I do:
>
> select * into temp xx from yy;
> drop table badname;
> select * into temp xxe from yy;
>
> it does not leave around the temp tables, but it if I add a second drop,
> it fails again, so it appears that I have to exit on a bad command to
> have the entries left around. Just issuing the select without the bad
> command cleans up properly, so I am left to believe that the failed
> command is doing something strange. My guess is that somehow the dirty
> marks on buffers is getting cleared by the bad command, and on exit, the
> new pg_class blocks are not getting put on disk.
>
> Tom Lane, you did the code that does special things when there is a
> failed command, right? It was because creating a table inside a failed
> transaction was leaving around the old cache entries. Could this be
> causing this problem?
I think I may know the cause. The at_exit removal of the temp tables is
taking place in a failed transaction. Let me test that idea tomorrow.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026