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 по дате отправления: