From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | pg_waldump vs. all-zeros WAL files; server creation of such files |
Date: | 2023-08-13 03:15:31 |
Message-ID: | 20230813031531.GC2326466@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The attached 010_zero.pl, when run as part of the pg_waldump test suite, fails
at today's master (c36b636) and v15 (1bc19df). It passes at v14 (5a32af3).
Command "pg_waldump --start 0/01000000 --end 0/01000100" fails as follows:
pg_waldump: error: WAL segment size must be a power of two between 1 MB and 1 GB, but the WAL file "000000010000000000000002" header specifies 0 bytes
Where it fails, the server has created an all-zeros WAL file under that name.
Where it succeeds, that file doesn't exist at all. Two decisions to make:
- Should a clean server shutdown ever leave an all-zeros WAL file? I think
yes, it's okay to let that happen.
- Should "pg_waldump --start $X --end $Y" open files not needed for the
requested range? I think no.
Bisect of master got:
30a53b7 Wed Mar 8 16:56:37 2023 +0100 Allow tailoring of ICU locales with custom rules
Doesn't fail at $(git merge-base REL_15_STABLE master). Bisect of v15 got:
811203d Sat Aug 6 11:50:23 2022 -0400 Fix data-corruption hazard in WAL-logged CREATE DATABASE.
I suspect those are innocent. They changed the exact WAL content, which I
expect somehow caused creation of segment 2.
Oddly, I find only one other report of this:
https://www.postgresql.org/message-id/CAJ6DU3HiJ5FHbqPua19jAD%3DwLgiXBTjuHfbmv1jCOaNOpB3cCQ%40mail.gmail.com
Thanks,
nm
Attachment | Content-Type | Size |
---|---|---|
010_zero.pl | application/x-perl | 545 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-08-13 06:25:33 | Re: Ignore 2PC transaction GIDs in query jumbling |
Previous Message | Peter Geoghegan | 2023-08-13 00:53:29 | Re: run pgindent on a regular basis / scripted manner |