From: Zsolt Parragi <zsolt.parragi@percona.com>
In-Reply-To: <20260515140302.5a532dfa246817a0b28854f7@sraoss.co.jp>
References: <20260324151133.7940a5c1f2ebd594d54da481@sraoss.co.jp>
 <CAA5RZ0snnePNW1NKGKh+NyJ1CY26T5F_6-tTq+BHWM2kj1fN1g@mail.gmail.com>
 <20260325012847.e026ba1860c07288efe3e97d@sraoss.co.jp>
 <20260326192203.e6dbb8d80f8d27dc15ceee59@sraoss.co.jp>
 <acW8MW-Gb8Aj_TH2@paquier.xyz>
 <20260327163549.b5df519c0099970ddbb3412d@sraoss.co.jp>
 <CAA5RZ0tNh03LLgJVMA=PXSdY8YVoui4_GyfbfTrYK5cka3Q9Rw@mail.gmail.com>
 <20260328161802.f35b5a3e739566ffd7c1053b@sraoss.co.jp>
 <20260413170551.5ec43ba5a2c848f0d46c6a0b@sraoss.co.jp>
 <CAA5RZ0tUHU-r=Tc47P2DZyytF7x5h5OwBiRABe_dZt+zWNqe9g@mail.gmail.com>
 <20260427203207.32aa6ca37f2a18a05508dfda@sraoss.co.jp>
 <CAA5RZ0vwgXZ5kF2GvYBR+Ma1LPSbDjE9pjANzSiUw3wmpv51PQ@mail.gmail.com>
 <CAN4CZFO5BAr2uP=2CDDyX5ydFw8Ku=wtJ0ZtfLTKuWvXH6J2yQ@mail.gmail.com>
 <CAA5RZ0v-xJ5fdTvNOdfokbY10pjjP=x_sfQ6Td30bbooomysaw@mail.gmail.com>
 <20260515140302.5a532dfa246817a0b28854f7@sraoss.co.jp>
MIME-Version: 1.0
Date: Fri, 15 May 2026 04:02:55 -0500
Message-ID: 
 <CAN4CZFMo=iosjuJR1kVTncfhb9mVu=d3dnTew6zgd42oTejj2w@mail.gmail.com>
Subject: Re: Track skipped tables during autovacuum and autoanalyze
To: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFMo%3DiosjuJR1kVTncfhb9mVu%3Dd3dnTew6zgd42oTejj2w%40mail.gmail.com>
Precedence: bulk

> If the table is dropped, there are no stats to update. right?

Ops, right. I focused too much on "all warnings should be visible in
the statistic, so the sum of warnings and statistics should match",
but of course that's not the case.

> However, I'm not entirely sure whether this behavior is always guaranteed.
> Could anyone clarify this?

There's another different corner-case if I move the injection point
inside pgstat_report_skipped_vacuum_analyze, after releasing the
syscache.

If the drop happens at that point, we insert an orphaned record into
the statistics, and it will be visible with the internal functions
(e.g. pg_stat_get_skipped_autoanalyze_count).

It is still invisible in the pg_stat_all_tables view, but now that
I've looked more at the code, I think internally it will stay there
permanently, even surviving pg_stat_reset?

> RangeVarGetRelid() still returns the table's OID

Yes, I also reached the same conclusion, I started testing because I
tried to see if I could break the double relid retrieval by some
scenarios (alter rename + create, drop-create etc), but it's not
possible. The ereports can execute CHECK_FOR_INTERRUPTS, but that
never calls ProcessCatchupInterrupt, and because of that it never runs
AccceptInvalidationMessages. And that's when I noticed that the
warning isn't visible in the statistics at all, and got distracted...