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
