Re: Possible race condition in pg_basebackup - Mailing list pgsql-hackers

From Nick Ivanov
Subject Re: Possible race condition in pg_basebackup
Date
Msg-id a0867ee8-3bcf-44f8-8ce8-64bf808f9ee3@enterprisedb.com
Whole thread
In response to Re: Possible race condition in pg_basebackup  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: remove_useless_joins vs. bug #19560
Next
From: Nick Ivanov
Date:
Subject: Re: Possible race condition in pg_basebackup