Re: Restore of a reference database kills the auto analyze processing.

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(dot)klaver(at)aklaver(dot)com