Re: Lowering the default wal_blocksize to 4K
От | Robert Haas |
---|---|
Тема | Re: Lowering the default wal_blocksize to 4K |
Дата | |
Msg-id | CA+TgmoaDtSxQuofrawMj1LnVxhZ3d1E=U8M3x9=f0zsnzJ-uCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Lowering the default wal_blocksize to 4K (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Lowering the default wal_blocksize to 4K
|
Список | pgsql-hackers |
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. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: