Re: Possible race condition in pg_basebackup

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Nick Ivanov <nick(dot)ivanov(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Possible race condition in pg_basebackup
Date: 2026-08-25 06:32:47
Message-ID: 5516902D-65A5-4C61-8568-E32F111C89EF@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro,

On Fri, Aug 21, 2026 at 6:35 PM Alvaro Herrera wrote:
> If you're using a version that contains these fixes, then we may have
> some slightly different bug ...

Yes, this is a different bug. I added a deterministic injection-point test
on current master, which already contains 006dd4b2e. It stops
BASE_BACKUP after selecting the startpoint but before sending it to the
client, recycles that WAL, and then observes pg_basebackup fail when its WAL
streamer starts. As a reproducer, the test succeeds only when pg_basebackup
fails with the expected missing-WAL error.

006dd4b2e protects an already created slot while it reserves WAL. In this
case no slot exists yet, so it cannot protect the earlier backup startpoint.

PFA the test patch.

Best regards, Andrey Borodin.

Attachment Content-Type Size
v1-0001-Demonstrate-WAL-recycling-race-in-pg_basebackup-cre.patch application/octet-stream 6.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-08-25 06:37:04 relpages value for partitioned tables
Previous Message Richard Guo 2026-08-25 06:29:04 Re: Fix CPU cost of right-semi and right-anti hash joins