Обсуждение: Strange issue with vacuum and temp tables

Поиск
Список
Период
Сортировка

Strange issue with vacuum and temp tables

От
Jeff Frost
Дата:
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

Re: Strange issue with vacuum and temp tables

От
Alvaro Herrera
Дата:
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.

Re: Strange issue with vacuum and temp tables

От
Tom Lane
Дата:
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

Re: Strange issue with vacuum and temp tables

От
Jeff Frost
Дата:
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