I'm running 7.3.1 and I seem to get a fair number of these as well. I have no
problems removing them, possibly because the processes associated with them are
really gone.
My best estimate as to when they appear is when I abort a transaction in
PGAdminII by killing the corresponding process on the server ("kill -9 XXXX"),
but that alone doesn't seem to account for all of them. I DEFINITELY never
have backend crashes - steady as a rock, and I love it for that :-).
This begs the question: what is a more elegant way to kill a runaway PGAdminII
transaction, when PGAdminII is running on Windows and I don't want to kill
PGAdminII itself (because it's executing a complex query I don't want to re-
write from scratch)?
Thanks,
Andrew
4/23/03 11:51:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>jboes@nexcerpt.com (Jeff Boes) writes:
>> I just noticed that there are a number of tables in our schema with
>> names fo the form pg_temp_*; these correspond to temporary tables
>> created by our application, but they shouldn't still exist. Under what
>> circumstances would a temporary table become permanent?
>
>In theory, never. Do you have frequent backend crashes? Is it possible
>that the backend sessions that created these tables are actually still
>running?
>
>If you're quite certain that the sessions that created those tables are
>dead, it is safe to issue DROPs against them. I am not sure whether you
>have to jump through any hoops to do so though --- the protection
>checks against dropping system tables look for "pg_XXX" and so are
>likely to mutiny :-(. You might need to run a standalone backend with
>the -O command-line switch to get around that protection check.
>
>PG 7.3 handles this scenario a little better, but I take it you haven't
>upgraded yet ...
>
> regards, tom lane
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>