Re: Resetting spilled txn statistics in pg_stat_replication

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> I am able to reproduce this problem via debugger. Basically, execute
> the Insert mentioned above from one the psql sessions and in
> ExecInsert() stop the execution once 'estate->es_processed > 4000' and
> then from another psql terminal execute some DDL which will be ignored
> but will any try to decode commit. Then perform 'continue' in the
> first session. This will lead to inconsistent stats value depending
> upon at what time DDL is performed. I'll push the patch as I am more
> confident now.

So ... doesn't this mean that if the concurrent transaction commits very
shortly after our query starts, decoding might stop without having ever
spilled at all? IOW, I'm afraid that the revised test can still fail,
just at a frequency circa one-twelfth of before.

I'm also somewhat suspicious of this explanation because it doesn't
seem to account for the clear experimental evidence that 32-bit machines
were more prone to failure than 64-bit.

regards, tom lane