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,
acrossthe 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@aklaver.com