| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Nick Ivanov <nick(dot)ivanov(at)enterprisedb(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Possible race condition in pg_basebackup |
| Date: | 2026-09-15 18:29:02 |
| Message-ID: | 2A5B29E9-658D-4AD7-8879-C6169D1327E3@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Nick,
On 11 Sep 2026, Nick Ivanov wrote:
> I agree, and I'm attaching a separate patch for that.
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.
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?
Best regards, Andrey Borodin.
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Test-WAL-retention-before-pg_basebackup-starts-st.patch | application/octet-stream | 6.2 KB |
| v3-0002-Create-pg_basebackup-s-replication-slot-before-st.patch | application/octet-stream | 5.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2026-09-15 18:30:34 | Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes |
| Previous Message | Andrey Borodin | 2026-09-15 18:13:26 | Re: Return pg_control from pg_backup_stop(). |