Message-ID: <a0867ee8-3bcf-44f8-8ce8-64bf808f9ee3@enterprisedb.com>
Date: Sat, 19 Sep 2026 14:48:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Possible race condition in pg_basebackup
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
 pgsql-hackers mailing list <pgsql-hackers@lists.postgresql.org>
References: <aoh9KdCo12Y07mZO@alvherre.pgsql>
 <5516902D-65A5-4C61-8568-E32F111C89EF@yandex-team.ru>
 <CALP_NYQZHLp4+so=JXJwVonP8Rkz2nx4uwRZOP1DXGtY_gW8eQ@mail.gmail.com>
 <99DF8255-F6B8-4B10-85A2-B6984B3DD16C@yandex-team.ru>
 <999caa0e-d015-42da-9b79-001087e719b8@enterprisedb.com>
 <0cab2102-4786-416a-ae50-b606a495d01b@enterprisedb.com>
 <801646A4-65A3-4DF1-84CD-7BF836E178BD@yandex-team.ru>
 <985de9f0-cbb6-4235-a6cd-32242f74e1f3@enterprisedb.com>
 <2A5B29E9-658D-4AD7-8879-C6169D1327E3@yandex-team.ru>
Content-Language: en-US
From: Nick Ivanov <nick.ivanov@enterprisedb.com>
In-Reply-To: <2A5B29E9-658D-4AD7-8879-C6169D1327E3@yandex-team.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a0867ee8-3bcf-44f8-8ce8-64bf808f9ee3%40enterprisedb.com>
Precedence: bulk

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