I saw an interesting problem at a client running PostgreSQL-8.2.4. The client
called me complaining of the good old database must be vacuumed before xx
transactions warning:

WARNING: database "lmdb" must be vacuumed within 10999793 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"lmdb".

Only thing is they were running autovacuum on 8.2.4. After some
investigation, and looking in the system views, I found that the cause of the
problems were old temp tables in pg_temp_* schemas.

Now, the backend had been restarted prior to me having a look at it, so I'm
not really sure how the tables are still hanging around. It seems that both
vacuum and autovacuum ignore pg_temp_* schemas and the fix was renaming the
schemas to something that didn't start with pg_temp and then running vacuum.
After that everything was fine.

A look at the code revealed that the temp tables were created via normal
methods, so I'm curious to know if there is a bug regarding temp tables not
going away on Postgresql-8.2.x after the connection is closed?

--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Jeff Frost <jeff@frostconsultingllc.com> writes:
> A look at the code revealed that the temp tables were created via normal
> methods, so I'm curious to know if there is a bug regarding temp tables not
> going away on Postgresql-8.2.x after the connection is closed?

You aren't the first to report such a thing, but nobody has the foggiest
idea how it could happen short of a backend crash. Have they had any
crashes lately (or more specifically, around the mod times of those
files, if you checked them)?

Also, were the pg_temp schemas you zapped particularly high-numbered?
Low-numbered ones would get cleaned out on the next use, but if the
crash happened at a peak in the number of active backends it's easy
to believe the files might hang around for awhile.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Jeff Frost wrote:

> A look at the code revealed that the temp tables were created via normal
> methods, so I'm curious to know if there is a bug regarding temp tables
> not going away on Postgresql-8.2.x after the connection is closed?

Well, a process crash could leave temp tables behind which causes the
problem. Otherwise I think they should go away normally ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Fri, 28 Mar 2008, Tom Lane wrote:

> Jeff Frost <jeff@frostconsultingllc.com> writes:
>> A look at the code revealed that the temp tables were created via normal
>> methods, so I'm curious to know if there is a bug regarding temp tables not
>> going away on Postgresql-8.2.x after the connection is closed?
>
> You aren't the first to report such a thing, but nobody has the foggiest
> idea how it could happen short of a backend crash. Have they had any
> crashes lately (or more specifically, around the mod times of those
> files, if you checked them)?
>
> Also, were the pg_temp schemas you zapped particularly high-numbered?
> Low-numbered ones would get cleaned out on the next use, but if the
> crash happened at a peak in the number of active backends it's easy
> to believe the files might hang around for awhile.

I inquired whether there had been crashes and they indicated no. I've
requested a mining through the logs to see if there were any backend crashes,
but probably won't get the info till next week.

Looks like the highest was pg_temp_534.

--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin