Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: will(at)extrahop(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon
Date: 2023-06-20 06:41:22
Message-ID: ZJFKEhxczWxMKhrL@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Japin Li 2023-06-20 08:17:33 Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction
Previous Message Thomas Munro 2023-06-20 01:22:19 Re: BUG #17949: Adding an index introduces serialisation anomalies.