public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zsolt Parragi <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Yugo Nagata <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Track skipped tables during autovacuum and autoanalyze
Date: Thu, 14 May 2026 22:46:47 +0100
Message-ID: <CAN4CZFO5BAr2uP=2CDDyX5ydFw8Ku=wtJ0ZtfLTKuWvXH6J2yQ@mail.gmail.com> (raw)
In-Reply-To: <CAA5RZ0vwgXZ5kF2GvYBR+Ma1LPSbDjE9pjANzSiUw3wmpv51PQ@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>
Hello!
+ TimestampTz last_skipped_vacuum_time; /* user initiated vacuum */
+ PgStat_Counter skipped_vacuum_count;
+ TimestampTz last_skipped_autovacuum_time; /* autovacuum initiated */
+ PgStat_Counter skipped_autovacuum_count;
+ TimestampTz last_skipped_analyze_time; /* user initiated */
+ PgStat_Counter skipped_analyze_count;
+ TimestampTz last_skipped_autoanalyze_time; /* autovacuum initiated */
+ PgStat_Counter skipped_autoanalyze_count;
+
Doesn't these also require a PGSTAT_FILE_FORMAT_ID change?
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
|
> 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.
Attachments:
[application/octet-stream] 0001-DROP-TABLE-race-in-expand_vacuum_rel-skip-lock-path.patch.nocfbot (3.1K, 2-0001-DROP-TABLE-race-in-expand_vacuum_rel-skip-lock-path.patch.nocfbot)
download
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: <CAN4CZFO5BAr2uP=2CDDyX5ydFw8Ku=wtJ0ZtfLTKuWvXH6J2yQ@mail.gmail.com>
* 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