Re: Lowering the default wal_blocksize to 4K

On Thu, 12 Oct 2023 at 16:36, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Oct 11, 2023 at 4:28 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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]

[1]
https://www.postgresql.org/message-id/CANwKhkMN3QwAcvuDZHb6wsvLRtkweBiYso-KLFykkQVWuQLcOw@mail.gmail.com
--

Ants Aasma
Senior Database Engineerwww.cybertec-postgresql.com