Re: BUG #16614: Stale temporary objects makes vacuum ineffective when 1 million transactions remain - Mailing list pgsql-bugs

From Giorgio Saviane
Subject Re: BUG #16614: Stale temporary objects makes vacuum ineffective when 1 million transactions remain
Date
Msg-id CAHs6c0eK9EctDoffiMU6=M=ct4+Pr5+OiZ00CjxS23C8s8J+CA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16614: Stale temporary objects makes vacuum ineffective when 1 million transactions remain  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
The connection pooler is a component embedded in the Tomcat container. When Tomcat stops the connection pooler gets shut down too. We can tell it by the number of Postgres processes that disappear from htop.
We never touch autovacuum settings, they are kept to the default.

Kind regards

Giorgio Saviane

Il giorno sab 12 set 2020 alle ore 20:18 Tom Lane <tgl@sss.pgh.pa.us> ha scritto:
Giorgio Saviane <gsaviane@gmail.com> writes:
> Ok, let me add one more step in that sequence.
> Before shutting down Postgres and going down to single mode we stopped the
> application server and other services around it. I'm pretty sure that there
> was a reasonable window of time before we went to single mode.

Hmm, but did you stop the connection pooler?  That's what was holding
the database session open, if I'm understanding things correctly.

Unless you've changed the default autovacuum settings (particularly
autovacuum_naptime), I'd have expected autovacuum to start zapping
temp tables within a minute or so after they become orphaned.
Even more to the point, if the database session was allowed to stop
normally, it should've cleaned them up itself.

                        regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16614: Stale temporary objects makes vacuum ineffective when 1 million transactions remain
Next
From: PG Bug reporting form
Date:
Subject: BUG #16615: Cannot determine type of Date for "is null" expression