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:41 +0000 (16:12 -0400)
commitab55d742eb7162c22ee60f1e15e07d2a60063c4e
treef208cfb0c4a8a1978531626453cd06ce97d82bdd
parent4efcf47053eaf8dd88de2b1a89478df43d37d5c0
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