Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correct oldtuplelen
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correct oldtuplelen |
Дата | |
Msg-id | CAB7nPqT4E95m58V-wTmrrG404P0jTpT+YqBE36_sVCyFtaaVSA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correct oldtuplelen (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correctoldtuplelen
|
Список | pgsql-bugs |
On Sun, Jan 1, 2017 at 9:06 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > OK, I can see the problem. And I can see as well that things have been > tackled in this area with 9.5 thanks to commit 2c03216d... (Adding Andres in CC for some input on the matter) Looking at that... As HeapTupleData->t_len is uint32, it is really an oversight in the 9.4 WAL logging machinery that xl_heap_header_len uses uint16. If xl_heap_update->flags still had a bit free, we could have for example use XLOG_HEAP_CONTAINS_OLD_TUPLE to track the existing short version of xl_heap_header_len and add a new bit for a "long" version where a version of xl_heap_header_len including uint32 as t_len is read. This would preserve replay from doing stupid things for existing 9.4 deployments and allow new records to work fully. But there are no bits free here. As well as there are no bits for XLOG_HEAP[1|2]. Andres, perhaps you have an idea? Looking at this code, It is worth noting that XLOG_HEAP_CONTAINS_OLD_TUPLE and XLOG_HEAP_CONTAINS_OLD_KEY are always used just for XLOG_HEAP_CONTAINS_OLD, so we could merge them and have a single flag to do the whole thing, the parent's replica identity value being here to track if a full version of the old tuple is logged or not. -- Michael -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: