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