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

Hi,

> VACUUM and ANALYZE overwrite live_tuples/dead_tuples in the shared stats
> entry with their own counts. Those counts already include the effects
> of transactions this backend committed earlier. But the matching deltas
> can still be pending in the backend's local stats, because pending
> stats are flushed at most once per PGSTAT_MIN_INTERVAL. They are then
> added again on top of the new values at the next flush

It looks like to me that those cases cases fall into the same category as [1]
which was ultimately not considered a bug.

> A related problem is in the same file. AtEOXact_PgStat_Relations()
> does
>
> relstat->tab.truncdropped = trans->truncdropped;
>
> on every commit. So if one transaction truncates a table and a later
> transaction of the same backend modifies it before the pending stats
> are flushed, the pending truncation reset is lost. No VACUUM or ANALYZE
> is needed for this one:
>
>
> -- t has 1000 rows, stats flushed
> TRUNCATE t;
> INSERT INTO t SELECT generate_series(1, 300);
> SELECT pg_stat_force_next_flush();
> -- n_live_tup = 1300 (count(*) = 300)

So maybe only the TRUNCATE case deserves a fix?

[1]: https://postgr.es/m/xnd433j72ixptoydkifnleke43bvql4rxrw4ohnodx6hk4wcho%40m46ab2bt33jh#07b7a951d9a983ce9432d6bf86979ff2

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com