Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon
Date
Msg-id ZJFKEhxczWxMKhrL@paquier.xyz
Whole thread Raw
In response to Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
On Mon, Jun 19, 2023 at 10:45:23AM -0700, Andres Freund wrote:
> I think it'd take a fair amount of work to track these stats in a more useful
> manner for the startup process, by virtue of it effectively being connected to
> multiple databases. We'd need to track
> pgStatBlockReadTime/pgStatBlockWriteTime on a per-database level, which
> wouldn't be easy to do without increasing overhead.

Is it really necessary to do this much amount of work for the scope of
this issue, though?  Relying on MyDatabaseId to control if these
updates should happen does not look like the right move to me, to be
honest, because this can be used to update shared stats.  In the
pgstat shutdown callback, shouldn't we try to check if the database
entry exists and/or has been dropped and just do nothing in this case?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #17949: Adding an index introduces serialisation anomalies.
Next
From: Japin Li
Date:
Subject: Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction