Re: BUG #17928: Standby fails to decode WAL on termination of primary
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Noah Misch <noah@leadboat.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-08-10T23:22:48Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Correct assertion and comments about XLogRecordMaxSize.
- e1f95ec8cf6e 17.0 landed
-
Fix edge-case for xl_tot_len broken by bae868ca.
- bde2f1847f51 12.17 landed
- 45d1fe8b53d4 13.13 landed
- 3d413c5a76fa 14.10 landed
- 99d334a187ae 15.5 landed
- 10d0591ea227 16.1 landed
- becfbdd6c1c9 17.0 landed
-
Don't use Perl pack('Q') in 039_end_of_wal.pl.
- 82314dbfca7f 12.17 landed
- 07896f468f23 13.13 landed
- afa504ba2f5d 14.10 landed
- 21b4c3ca0b22 15.5 landed
- cc58607b019a 16.1 landed
- 91b0e85aa0ad 17.0 landed
-
Don't trust unvalidated xl_tot_len.
- e8f3c0687116 12.17 landed
- 6606c57162cb 13.13 landed
- 3ce3b53d76a3 14.10 landed
- f4d152edd8f3 15.5 landed
- ce497f648e2d 16.1 landed
- bae868caf222 17.0 landed
-
Make recovery report error message when invalid page header is found.
- 7b03d3a3ba45 12.17 landed
- 5dc093eacef1 13.13 landed
- 2f13e8d9ec28 14.10 landed
-
Add more protections in WAL record APIs against overflows
- 8fcb32db98ed 16.0 cited
On Thu, Aug 10, 2023 at 04:45:25PM +0900, Michael Paquier wrote: > On Sun, Jul 16, 2023 at 05:49:05PM -0700, Noah Misch wrote: >> - Use pg_logical_emit_message to fill a few segments with 0xFF. >> - CHECKPOINT the primary, so the standby recycles segments. >> - One more pg_logical_emit_message, computing the length from >> pg_current_wal_insert_lsn() such that new message crosses a segment boundary >> and ends 4 bytes before the end of a page. >> - Stop the primary. >> - If the bug is present, the standby will exit. > > Good idea to pollute the data with recycled segments. Using a minimal > WAL segment size whould help here as well in keeping a test cheap, and > two segments should be enough. The alignment calculations and the > header size can be known, but the standby records are an issue for the > predictability of the test when it comes to adjust the length of the > logical message depending on the 8k WAL page, no? Actually, for this one, I think that I have a simpler idea to make it deterministic. Once we have inserted a record at the page limit on the primary, we can: - Stop the standby - Stop the primary - Rewrite by ourselves a few bytes in the last segment on the standby to emulate a recycled segment portion, based on the end LSN of the logical message record, retrieved either with pg_walinspect or pg_waldump. - Start the standby, which would replay up to the previous record at the page limit. - The standby just be in a state where it waits for the missing records from the primary and keeps looking at streaming, but it should not fail startup. -- Michael