public inbox for [email protected]
help / color / mirror / Atom feedFrom: Yugo Nagata <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Track skipped tables during autovacuum and autoanalyze
Date: Fri, 15 May 2026 14:03:02 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0v-xJ5fdTvNOdfokbY10pjjP=x_sfQ6Td30bbooomysaw@mail.gmail.com>
References: <[email protected]>
<CAA5RZ0snnePNW1NKGKh+NyJ1CY26T5F_6-tTq+BHWM2kj1fN1g@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA5RZ0tNh03LLgJVMA=PXSdY8YVoui4_GyfbfTrYK5cka3Q9Rw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAA5RZ0tUHU-r=Tc47P2DZyytF7x5h5OwBiRABe_dZt+zWNqe9g@mail.gmail.com>
<[email protected]>
<CAA5RZ0vwgXZ5kF2GvYBR+Ma1LPSbDjE9pjANzSiUw3wmpv51PQ@mail.gmail.com>
<CAN4CZFO5BAr2uP=2CDDyX5ydFw8Ku=wtJ0ZtfLTKuWvXH6J2yQ@mail.gmail.com>
<CAA5RZ0v-xJ5fdTvNOdfokbY10pjjP=x_sfQ6Td30bbooomysaw@mail.gmail.com>
On Thu, 14 May 2026 19:59:18 -0500
Sami Imseih <[email protected]> wrote:
> > Doesn't these also require a PGSTAT_FILE_FORMAT_ID change?
>
> right. that was missed. Fixed in the attached.
Thank you for updating the patch.
>
> > There's also an asymmetric case for the skipped counters, is that intentional?
> >
> > | Command | `skipped_vacuum_count` |
> > `skipped_analyze_count` |
> > |-----------------------------------------|------------------------|-------------------------|
> > | `VACUUM (FULL, ANALYZE, SKIP_LOCKED) t` | 0 | 1
> > |
> > | `VACUUM (ANALYZE, SKIP_LOCKED) t` | 1 | 1
> > |
> > | `VACUUM (FULL, SKIP_LOCKED) t` | 0 | 0
>
> Yeah, this is because vacuum_count and last_vacuum also skip VACUUM FULL.
> That was mentioned earlier in the thread.
Right.
> > > Initially, I was concerned that something might go wrong if a concurrent
> > > session performed DROP TABLE or ALTER TABLE RENAME between RangeVarGetRelidExtended()
> > > and RangeVarGetRelid(), but I could not find any actual issue. Even when the table
> > > name is changed, the correct statistics entry is updated correctly.
> >
> > A DROP TABLE can cause a missed skip in statistics, which is
> > reproducible with a custom injection point and tap test, see the
> > attached patch. The race window is quite minimal, but it exists.
>
> If the table is dropped, there are no stats to update. right?
In my analysis, even if the table is dropped or renamed just before calling RangeVarGetRelid()
(at the injection point you added), RangeVarGetRelid() still returns the table's OID. So it
seems possible that the statistics entry is updated locally, but it would be released shortly
afterward and thus eventually becomes invisible.
However, I'm not entirely sure whether this behavior is always guaranteed.
Could anyone clarify this?
Regards,
Yugo Nagata
--
Yugo Nagata <[email protected]>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Track skipped tables during autovacuum and autoanalyze
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox