Обсуждение: Strange issue with vacuum and temp tables
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
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.
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
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