Re: Possible race condition in pg_basebackup

Hello Andrey,

On 15/09/2026 19:29, Andrey Borodin wrote:
> Hi Nick,
>
> Thanks! This looks like the right scope for a backpatch.
>
> I adapted your v2 test for the client-side fix, checking that the slot
> already reserves WAL before the server sends the startpoint. It covers
> both --create-slot and the default temporary slot, and requires the
> backup to succeed after the concurrent checkpoint. Without the fix,
> both cases fail with the expected missing-WAL error.

Thank you for updating the test, much appreciated. I should have done
that myself, to be honest.

> Small wording detail. Another checkpoint is enough to trigger the race.
> It need not come from another basebackup. I adjusted and wrapped the
> commit message accordingly. Apart from wrapping a comment, the client
> code is unchanged.
>
> WDYT?

The changes make good sense, thanks for that too.

I will now proceed to validate the patch against older versions. One
question in that regard: the TAP test carries the number 57 in the
recovery suite in the master branch. Earlier stable versions likely have
fewer tests, and if we add the new test there with #57 there will be a
gap in the sequence. What is the accepted practice in such cases:
renumber the newly added test in earlier versions to avoid the gap, or
keep the number consistent with HEAD?

Cheers

Nick