On Wed, Oct 11, 2023 at 4:28 PM Thomas Munro <thomas.munro@gmail.com> wrote: > 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.
Hmm. Even in that case, xl_prev has to match. It's not like it's the wild west. Sure, it's not nearly as good of a cross-check, but it's something. It seems to me that it's not worth worrying very much about xlp_seg_size or xlp_blcksz changing undetected in that scenario - if you're doing that kind of advanced magic, you need to be careful enough to not mess it up, and if we still cross-check once per checkpoint cycle that's pretty good. I do worry a bit about the sysid changing under us, though. It's not that hard to get your WAL archives mixed up, and it'd be nice to catch that right away.
This reminds me that xlp_tli is not being used to its full potential right now either. We only check that it's not going backwards, but there is at least one not very hard to hit way to get postgres to silently replay on the wrong timeline. [1]
