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,
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