On Thu, 21 Mar 2024 at 14:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Rowley <dgrowle...@gmail.com> writes: > > We could also do something like the attached just in case we're > > barking up the wrong tree. > > Yeah, checking indisvalid isn't a bad idea. I'd put another > one further down, just before the DROP of table ab, so we > can see the state both before and after the unstable tests.
So it's taken quite a while to finally fail again. Effectively, we're getting: relname | relpages | reltuples | indisvalid | autovacuum_count | autoanalyze_count ----------------+----------+-----------+------------+------------------+------------------- - ab_a2_b2 | 0 | -1 | | 0 | 0 + ab_a2_b2 | 0 | 48 | | 0 | 0 I see AddNewRelationTuple() does set reltuples to -1, so I can't quite figure out why 48 is in there. Even if auto-analyze had somehow mistakenly run and the autoanalyze_count stats just were not up-to-date yet, the table has zero blocks, and I don't see how acquire_sample_rows() would set *totalrows to anything other than 0.0 in this case. For the vacuum case, I see that reltuples is set from: /* now we can compute the new value for pg_class.reltuples */ vacrel->new_live_tuples = vac_estimate_reltuples(vacrel->rel, rel_pages, vacrel->scanned_pages, vacrel->live_tuples); Again, hard to see how that could come to anything other than zero given that rel_pages and scanned_pages should be 0. Looking at the binary representation of a float of -1 vs 48, they're not nearly the same. 0xBF800000 vs 0x42400000, so it's not looking like a flipped bit. It would be good to have log_autovacuum_min_duration = 0 on this machine for a while. David