]> granicus.if.org Git - postgresql/commit
logical decoding: Fix handling of large old tuples with replica identity full.
authorAndres Freund <andres@anarazel.de>
Sun, 6 Mar 2016 02:02:20 +0000 (18:02 -0800)
committerAndres Freund <andres@anarazel.de>
Sun, 6 Mar 2016 02:02:20 +0000 (18:02 -0800)
commitc8f621c43a599b35dc004ee09627bf4688cbbb84
tree0d8ecce142f1bc0aad939f73926c9646a86d59d7
parent0bda14d54cf24dedcd2011559a53cc62702e421b
logical decoding: Fix handling of large old tuples with replica identity full.

When decoding the old version of an UPDATE or DELETE change, and if that
tuple was bigger than MaxHeapTupleSize, we either Assert'ed out, or
failed in more subtle ways in non-assert builds.  Normally individual
tuples aren't bigger than MaxHeapTupleSize, with big datums toasted.
But that's not the case for the old version of a tuple for logical
decoding; the replica identity is logged as one piece. With the default
replica identity btree limits that to small tuples, but that's not the
case for FULL.

Change the tuple buffer infrastructure to separate allocate over-large
tuples, instead of always going through the slab cache.

This unfortunately requires changing the ReorderBufferTupleBuf
definition, we need to store the allocated size someplace. To avoid
requiring output plugins to recompile, don't store HeapTupleHeaderData
directly after HeapTupleData, but point to it via t_data; that leaves
rooms for the allocated size.  As there's no reason for an output plugin
to look at ReorderBufferTupleBuf->t_data.header, remove the field. It
was just a minor convenience having it directly accessible.

Reported-By: Adam DratwiƄski
Discussion: CAKg6ypLd7773AOX4DiOGRwQk1TVOQKhNwjYiVjJnpq8Wo+i62Q@mail.gmail.com
contrib/test_decoding/expected/toast.out
contrib/test_decoding/sql/toast.sql
src/backend/replication/logical/decode.c
src/backend/replication/logical/reorderbuffer.c
src/include/replication/reorderbuffer.h