Re: Lowering the default wal_blocksize to 4K
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Matthias van de Meent <boekewurm+postgres@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2023-10-11T20:27:33Z
Lists: pgsql-hackers
On Thu, Oct 12, 2023 at 9:05 AM Robert Haas <robertmhaas@gmail.com> wrote: > But if we do want to keep those cross-checks, why not take what Thomas > proposed a little further and move all of xlp_sysid, xlp_seg_size, and > xlp_xlog_blcksz into XLOG_CHECKPOINT_REDO? Then long and short page > headers would become identical. FTR that's exactly what I was trying to say. > We'd lose the ability to recheck those > values for every new segment, but it seems quite unlikely that any of > these values would change in the middle of replay. If they did, would > xl_prev and xl_crc be sufficient to catch that? I think Andres says in > a later email that they would be, and I think I'm inclined to agree. > False xl_prev matches don't seem especially unlikely, but xl_crc seems > like it should be effective. Right, it is strong enough, and covers the common case where a record crosses the segment boundary. That leaves only the segments where a record starts exactly on the first usable byte of a segment, which is why I was trying to think of a way to cover that case too. I suggested we could notice and insert a new record at that place. But Andres suggests it would be too expensive and not worth worrying about.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
During online checkpoints, insert XLOG_CHECKPOINT_REDO at redo point.
- afd12774ae89 17.0 landed