Fix multiple crasher bugs in partitioned-table replication logic.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 11 Jun 2021 20:12:36 +0000 (16:12 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 11 Jun 2021 20:12:36 +0000 (16:12 -0400)
commitb270713fd44b1378cebc3177e092add0155b55b6
treea36bcbf0b58d01fe7cb1b61e702dcfb471f9638f
parent218b101008b533156d7e5832fe143d1e04a01301
Fix multiple crasher bugs in partitioned-table replication logic.

apply_handle_tuple_routing(), having detected and reported that
the tuple it needed to update didn't exist, tried to update that
tuple anyway, leading to a null-pointer dereference.

logicalrep_partition_open() failed to ensure that the
LogicalRepPartMapEntry it built for a partition was fully
independent of that for the partition root, leading to
trouble if the root entry was later freed or rebuilt.

Meanwhile, on the publisher's side, pgoutput_change() sometimes
attempted to apply execute_attr_map_tuple() to a NULL tuple.

The first of these was reported by Sergey Bernikov in bug #17055;
I found the other two while developing some test cases for this
sadly under-tested code.

Diagnosis and patch for the first issue by Amit Langote; patches
for the others by me; new test cases by me.  Back-patch to v13
where this logic came in.

Discussion: https://postgr.es/m/17055-9ba800ec8522668b@postgresql.org
src/backend/replication/logical/relation.c
src/backend/replication/logical/worker.c
src/backend/replication/pgoutput/pgoutput.c
src/test/subscription/t/001_rep_changes.pl
src/test/subscription/t/013_partition.pl