On Thu, 21 Mar 2024 at 14:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@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