Re: VACUUM/ANALYZE double-count the backend's own pending table stats

Hi Manu, Sebastian,

Thanks a lot for the review, the stress testing and the autovacuum
numbers, and for finding 81e82a2bd48.

v2 attached:

0001 is v1 plus a pinned test. Pending stats are only flushed while
the backend is idle, so the TRUNCATE and ANALYZE cases now run inside
a procedure, with a COMMIT between the steps. Nothing can be flushed
in between, whatever the timing. I checked that on unpatched master
the test still fails with pg_sleep(1.5) between the steps (n_live_tup
12 and 13 instead of 6 and 3). VACUUM can't run in a procedure, so the
VACUUM case is still best effort: if a flush slips in between the
INSERT and the VACUUM, it passes without testing anything, but it
can't fail spuriously. Manu, if you had a way to pin that one too,
I'd be glad to use it.

0002 is Manu's ins_since_vacuum delta, unchanged. I kept it as a
separate patch with Manu as the author. It looks right to me:
ins_before_vacuum lives only in the pending entry, which is freed after
a successful flush. tuples_inserted only grows while the entry is
pending, so the difference can't go negative. A second VACUUM simply
re-assigns it. On top of v1, it also passes my edge cases (2PC
TRUNCATE, relcache invalidation between the INSERT and the ANALYZE,
TOAST, matview, partitioned table, ANALYZE of a column list, and a
database-wide VACUUM ANALYZE with assertions enabled).

Both apply cleanly to current master (73e69062c).

Manu, about the two pre-existing TRUNCATE/subtransaction cases: yes,
please send the repros. Since they aren't caused by this patch, maybe
they would be better handled as a separate patch, so that this one
stays small enough to back-patch. Sebastian's numbers show that 14-18
are affected too. I can prepare back-branch versions if a committer
wants them.

--
Ilya Staroverov