Re: Minimal logical decoding on standbys
От | Robert Haas |
---|---|
Тема | Re: Minimal logical decoding on standbys |
Дата | |
Msg-id | CA+TgmoYTTsxP8y6uknZvCBNCRq+1FJ4zGbX8Px1TGW459fGsaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Minimal logical decoding on standbys (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Minimal logical decoding on standbys
|
Список | pgsql-hackers |
On Tue, Dec 20, 2022 at 3:39 PM Robert Haas <robertmhaas@gmail.com> wrote: > I think this might be the only WAL record type where there's a > problem, but I haven't fully confirmed that yet. It's not. GIST has the same issue. The same test case demonstrates the problem there, if you substitute this test script for kpt_hash_setup.sql and possibly also run it for somewhat longer. One might think that this wouldn't be a problem, because the comments for gistxlogDelete say this: /* * In payload of blk 0 : todelete OffsetNumbers */ But it's not in the payload of blk 0. It follows the main payload. This is the reverse of xl_heap_freeze_page, which claims that freeze plans and offset numbers follow, but they don't: they're in the data for block 0. xl_btree_delete is also wrong, claiming that the data follows when it's really attached to block 0. I guess whatever else we do here, we should fix the comments. Bottom line is that I think the two cases that have alignment issues as coded are xl_hash_vacuum_one_page and gistxlogDelete. Everything else is OK, as far as I can tell right now. -- Robert Haas EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: