Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon
Will Mortensen <will@extrahop.com>
From: Will Mortensen <will@extrahop.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, pgsql-bugs@lists.postgresql.org, Jacob Speidel <jacob@extrahop.com>
Date: 2023-06-16T01:36:41Z
Lists: pgsql-bugs
On Thu, Jun 15, 2023 at 6:01 PM Michael Paquier <michael@paquier.xyz> wrote: > It requires a few manual steps, but I have been able to stuck the > autovacuum launcher schedule. Nice investigation from the reporters. > > I may be missing something here, but finishing with an inconsistent > database list (generated based on the pgstat database entries) in the > autovacuum launcher is not something that can happen only because of a > worker, right? A normal backend would call pgstat_update_dbstats() > once it exists, re-creating a fresh entry with the dropped database > OID. Is that right? Yes, sorry, Jacob was able to repro with a normal backend just now. We probably should have tried that earlier. :-) I'm also unsure if reiniting the pgstats entry (as opposed to creating a new one) is actually necessary or just what we happened to observe. We're definitely not very familiar with these internals. :-)
Commits
-
Fix handling of shared statistics with dropped databases
- 5a9325fdde1d 15.5 landed
- c397c98ae63d 16.0 landed
- 2b8e5273e949 17.0 landed
-
Accept fractional seconds in jsonpath's datetime() method.
- bd590d1fea1b 15.4 cited