Re: Replication slot stats misgivings

vignesh C <vignesh21(at)gmail(dot)com> writes:
> On Wed, May 12, 2021 at 9:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Is there any value in converting the test case into a TAP test that
>> could be more flexible about the expected output? I'm mainly wondering
>> whether there are any code paths that this test forces the server through,
>> which would otherwise lack coverage.

> Removing this test does not reduce code coverage. This test is
> basically to decode and check the stats again, it is kind of a
> repetitive test. The problem with this test here is that when a
> transaction is spilled, the statistics for the spill transaction will
> be sent to the statistics collector as and when the transaction is
> spilled. This test sends spill stats around 12 times. The test expects
> to reset the stats and check the stats gets updated when we get the
> changes. We cannot validate reset slot stats results here, as it could
> be possible that in some machines the stats collector receives the
> spilled transaction stats after getting reset slots. This same problem
> will exist with tap tests too. So I feel it is better to remove this
> test.

OK, I'm satisfied as long as we've considered the code-coverage angle.

regards, tom lane