Re: Lowering the default wal_blocksize to 4K

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: Lowering the default wal_blocksize to 4K
Дата
Msg-id CANwKhkPYoxr=JVb9dVn6gyLMkzY5cE7NaZArBfJqi3A-LM1+3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lowering the default wal_blocksize to 4K  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Lowering the default wal_blocksize to 4K  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 12 Oct 2023 at 16:36, Robert Haas <robertmhaas@gmail.com> wrote:
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]
 
--
Ants Aasma
Senior Database Engineer
www.cybertec-postgresql.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Glukhov
Дата:
Сообщение: Re: Problem, partition pruning for prepared statement with IS NULL clause.
Следующее
От: David Steele
Дата:
Сообщение: Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"