Fix handling of pgstat counters for TRUNCATE in a prepared transaction.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Oct 2016 23:45:58 +0000 (19:45 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Oct 2016 23:45:58 +0000 (19:45 -0400)
commit3cd504254f604a37adefc2bd9d43a0a6041463fd
tree7d3c5f95cc78796be7688242076e6dbf6198843a
parent3217ac3a98673b1520d774f2a61fffc237874e47
Fix handling of pgstat counters for TRUNCATE in a prepared transaction.

pgstat_twophase_postcommit is supposed to duplicate the math in
AtEOXact_PgStat, but it had missed out the bit about clearing
t_delta_live_tuples/t_delta_dead_tuples for a TRUNCATE.

It's harder than you might think to replicate the issue here, because
those counters would only be nonzero when a previous transaction in
the same backend had added/deleted tuples in the truncated table,
and those counts hadn't been sent to the stats collector yet.

Evident oversight in commit d42358efb.  I've not added a regression
test for this; we tried to add one in d42358efb, and had to revert it
because it was too timing-sensitive for the buildfarm.

Back-patch to 9.5 where d42358efb came in.

Stas Kelvich

Discussion: <EB57BF68-C06D-4737-BDDC-4BA778F4E62B@postgrespro.ru>
src/backend/postmaster/pgstat.c