Stas Kelvich <s.kelvich@postgrespro.ru> writes:
> Statistics sender logic during usual commit and two-phase commit do not
> strictly matches each other and that leads to delta_live_tuples added to
> n_live_tup in case of truncate in two phase commit.
Yeah, that code says it's supposed to match AtEOXact_PgStat, but it
doesn't.
I pushed this, but without the regression test case, which would have
failed outright in any test run with max_prepared_transactions = 0.
Timing sensitivity is another problem. In the commit that created this
discrepancy, d42358efb, Alvaro had tried to add regression coverage for
this area, but we ended up backing it out because it failed too often
in the buildfarm.
TBH, now that I look at it, I think that d42358efb was fundamentally
wrong and this patch is just continuing down the same wrong path.
Having the stats collector respond to a TRUNCATE like this cannot
work reliably, because the "it got truncated" flag will arrive at
the stats collector asynchronously, perhaps quite some time later
than the truncate occurred. When that happens, we may throw away
live/dead tuple count updates from transactions that actually happened
after the truncate but chanced to report first.
I wonder if we could make that better by making the stats collector
track stats by relfilenode rather than table OID. It'd be a pretty
major logic change, though, to serve a corner case.
regards, tom lane
