| 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 |
| 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 |