Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correctoldtuplelen
От | Andres Freund |
---|---|
Тема | Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correctoldtuplelen |
Дата | |
Msg-id | 20170805220606.mnyu2q2toqwl7nmn@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] [BUG] pg9.4.10 Logical decoding did not get the correctoldtuplelen (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On 2017-01-05 06:48:20 -0800, Andres Freund wrote: > On 2017-01-05 13:09:28 +0900, Michael Paquier wrote: > > 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. > > That sounds like a bad idea to me. But I don't have one a lot better, > and as you say the knowledge is currently not required. If both bits > are set it's a 32bit len, otherwise 16. Yay. There luckily is a better solution: We can just disregard the old tuple's t_len, and compute it via r->xl_len -#size-of-all-new-tuple-stuff. There's really no need for the new tuple's t_len via xl_heap_header_len. Pushed a fix. Could have removed copying of xl_heap_header_len in DecodeUpdate(), but decided that to go as small as possible. - Andres -- 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 по дате отправления: