On 5/22/24 01:33, HORDER Philip wrote:
Classified as: {OPEN}
2) There is a round of autovacuum immediately after the lfm is restored.
Yes, some tables in the lfm database, but not all, an apparently random selection, anywhere between 2 and 21 tables, across the lfm schemas, public & pg_catalog.
3) autovacuum then goes silent.
Yes. Dead in a ditch. But with no errors.
4) Before the next drop/create lfm you restart the Postgres server and autovacuum starts again.
I haven't restarted in a week, and the pattern remains, with a bit of analyze at each reload of lfm, and then nothing.
What is in the logs when you do the restart?
Nothing notable:
1) denied connections, while restarting
2) authorized connections
3) auto analyze going into overdrive:
See below
Is there some process that runs shortly after the drop/create lfm cycle?
Not that I can see.
I was hoping more coffee would lead to enlightenment, it did not. It did
lead me to do what I should have done at the start which is look at the
release notes for 15.x. You are on Postgres 15.3 and current is 15.7. On
the path from .5 --> .7 is:
https://www.postgresql.org/docs/15/release-15-5.html#id-1.11.6.7.4
Fix race condition in database dropping that could lead to the
autovacuum launcher getting stuck (Andres Freund, Will Mortensen, Jacob
Speidel)
The race could lead to a statistics entry for the removed database
remaining present, confusing the launcher's selection of which database
to process.
Phil Horder
Database Mechanic
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
