Re: [PATCH] Speed up pg_waldump TAP test and fix some GitHub CI Windows flakiness

Hi,

On Mon, 31 Aug 2026 at 10:53, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Fri, Aug 28, 2026 at 11:43:54PM -0400, Sehrope Sarkuni wrote:
> > Was testing a rebased Windows patch using GitHub CI and had some flaky slow
> > test timeout errors for an unrelated pg_waldump test. On Windows (and only
> > Windows) it was running for 500+ seconds and timing out. After a bit of
> > research, I figured it's because of the notoriously slow spoofed IPC that
> > perl does for the forked pg_waldump invocations (that then gets grepped by
> > perl).
>
> Your simple patch is also proving to make my runs of this test sort of
> 40% faster on Linux, at quick glance.

Yes, thank you for the patch! I confirm that runtime dropped from ~400
seconds to ~100 seconds on Windows CI.

> The --limit=1 additions are no-brainers in the commands where we don't
> expect specific outputs and/or records. Same thing can be said for
> the few --limit=5 cases, where I guess you've just chosen a number to
> be representative enough for the output. This number looks fine here.

Doesn't '--limit N' decrease coverage? For example,

`
@lines =
test_pg_waldump($path, $start_lsn, $end_lsn, '--rmgr' => 'Btree');
is(grep(!/^rmgr: Btree/, @lines), 0, 'only Btree lines');
`

was checking all Btree records from $start to $end. However,

`
@lines = test_pg_waldump(
$path, $start_lsn, $end_lsn,
'--rmgr' => 'Btree',
'--limit' => 5);
is(grep(!/^rmgr: Btree/, @lines), 0, 'only Btree lines');
`

checks the first 5 Btree records. Is that enough?

Also, if I am not mistaken, after this patch there is no test that
confirms pg_waldump runs correctly from start to end.

> - my @lines = test_pg_waldump($path, $start_lsn, $end_lsn);
> - is(grep(!/^rmgr: \w/, @lines), 0, 'all output lines are rmgr lines');
> -
> - @lines = test_pg_waldump($path, $contrecord_lsn, $end_lsn);
> + my @lines = test_pg_waldump($path, $contrecord_lsn, $end_lsn);
>
> Does this removal imply a loss of coverage?

I think you are right. At least, we lose coverage of tar and gzip inputs.

--
Regards,
Nazir Bilal Yavuz
Microsoft