Re: Restore of a reference database kills the auto analyze processing. - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Restore of a reference database kills the auto analyze processing.
Date
Msg-id ddac796c-fe21-478f-be5d-a5944b6722d8@aklaver.com
Whole thread Raw
In response to Re: Restore of a reference database kills the auto analyze processing.  (HORDER Philip <Phil.Horder@uk.thalesgroup.com>)
List pgsql-general
On 5/21/24 13:44, HORDER Philip wrote:
> Classified as: {OPEN}
> 
> 2024-05-15 03:31:31.290 GMT [4556]: [3-1]
> db=lfm,user=superuser,app=[unknown],client=::1 LOG:  connection
> authorized: user=superuser database=lfm application_name=pg_restore
> 
>> That would be the lfm database being restored.
>> What does the log show after that as pertains to autovacuum?
> 
> Yep, pg_restore recreates the dropped lfm database.
> And after that.... nothing.
> The log just holds connection requests, and a checkpoint every hour.
> That's it.
> No "automatic vacuum", or "automatic analyze" anywhere.
> And nothing any day since then, for a week.


Just for confirmation your settings are still?:

autovacuum_max_workers = 10
log_autovacuum_min_duration = 0

You said previously:

"The only way I can find of getting the analyzer back is to restart 
Postgres."

To be clear this means:

1) The lfm database is dropped/created.

2) There is a round of autovacuum immediately after the lfm is restored.

3) autovacuum then goes silent.

4) Before the next drop/create lfm you restart the Postgres server and 
autovacuum starts again.

What is in the logs when you do the restart?

Is there some process that runs shortly after the drop/create lfm cycle?

> 
> Phil Horder
> Database Mechanic
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




pgsql-general by date:

Previous
From: Senor Cervesa
Date:
Subject: vacuum an all frozen table
Next
From: Dmitry O Litvintsev
Date:
Subject: Confusing error message in 15.6