Thread: autovacuum: found orphan temp table
Hello, While it is obvious what is happening in $SUBJECT as well as reasonably obvious why it can happen. What isn't obvious is what to do about it. It seems we log in as a super user and drop the temp tables. However, I would think if we know that it is orphaned that autovacuum should just clean those up? JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, @cmdpromptinc "If we send our children to Caesar for their education, we should not be surprised when they come back as Romans."
Joshua D. Drake wrote: Hi, > While it is obvious what is happening in $SUBJECT as well as > reasonably obvious why it can happen. What isn't obvious is what to > do about it. It seems we log in as a super user and drop the temp > tables. > > However, I would think if we know that it is orphaned that > autovacuum should just clean those up? As far as I recall, if you wait long enough it will drop them. Looking at the code: yes, it's forcibly dropped when it becomes a problem for xid wraparound. Of course, you can drop it as superuser as well; that will save you a few months of WARNING spam ... Cheers -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
"Joshua D. Drake" <jd@commandprompt.com> writes:
> While it is obvious what is happening in $SUBJECT as well as reasonably
> obvious why it can happen. What isn't obvious is what to do about it. It
> seems we log in as a super user and drop the temp tables.
You don't need to do anything --- the table will go away the next time
a session makes use of that pg_stat_temp schema.
> However, I would think if we know that it is orphaned that autovacuum
> should just clean those up?
That seems to me to be outside the charter of autovacuum, particularly
since orphan tables might be of interest for forensic reasons.
regards, tom lane