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