> 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...
