From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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-21 03:59:06 |
Message-ID: | 20230621035906.3juv3dwo6afm7vpu@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2023-06-20 15:41:22 +0900, Michael Paquier wrote:
> 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?
No! That'd just be for actually making db-level stats for the startup process
work. In other words, I don't think there's anything we could break, because
it already doesn't work :)
> 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.
Shared stats only make sense when you know what non-shared stats are. At the
moment that afaict only works (and afaict only ever has worked) for database
connected backends.
I guess we could start reporting everything to the shared entry if we aren't
connected to a database, but that doesn't really seem like an improvement.
> 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?
I don't think that'd be a good approach.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-06-21 04:11:05 | Re: BUG #17986: Inconsistent results of SELECT affected by btree index |
Previous Message | Japin Li | 2023-06-21 01:45:23 | Re: BUG #17983: Assert IsTransactionState() failed when empty string statement prepared in aborted transaction |