Fix construction of updated-columns bitmap in logical replication.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Jul 2020 17:40:16 +0000 (13:40 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Jul 2020 17:40:16 +0000 (13:40 -0400)
Commit b9c130a1f failed to apply the publisher-to-subscriber column
mapping while checking which columns were updated.  Perhaps less
significantly, it didn't exclude dropped columns either.  This could
result in an incorrect updated-columns bitmap and thus wrong decisions
about whether to fire column-specific triggers on the subscriber while
applying updates.  In HEAD (since commit 9de77b545), it could also
result in accesses off the end of the colstatus array, as detected by
buildfarm member skink.  Fix the logic, and adjust 003_constraints.pl
so that the problem is exposed in unpatched code.

In HEAD, also add some assertions to check that we don't access off
the ends of these newly variable-sized arrays.

Back-patch to v10, as b9c130a1f was.

Discussion: https://postgr.es/m/CAH2-Wz=79hKQ4++c5A060RYbjTHgiYTHz=fw6mptCtgghH2gJA@mail.gmail.com

src/backend/replication/logical/worker.c
src/test/subscription/t/003_constraints.pl

index 32437202fe5b10a46ed8157582c9d22b26f9232c..ef65cb9922476cbc001ff36be9f07b5a06b60730 100644 (file)
@@ -748,9 +748,16 @@ apply_handle_update(StringInfo s)
    target_rte = list_nth(estate->es_range_table, 0);
    for (i = 0; i < remoteslot->tts_tupleDescriptor->natts; i++)
    {
-       if (newtup.changed[i])
-           target_rte->updatedCols = bms_add_member(target_rte->updatedCols,
-                                                    i + 1 - FirstLowInvalidHeapAttributeNumber);
+       Form_pg_attribute att = TupleDescAttr(remoteslot->tts_tupleDescriptor, i);
+       int         remoteattnum = rel->attrmap[i];
+
+       if (!att->attisdropped && remoteattnum >= 0)
+       {
+           if (newtup.changed[remoteattnum])
+               target_rte->updatedCols =
+                   bms_add_member(target_rte->updatedCols,
+                                  i + 1 - FirstLowInvalidHeapAttributeNumber);
+       }
    }
 
    PushActiveSnapshot(GetTransactionSnapshot());
index 62123792e6a90f4047418abddfb8102f13e44a0a..9f00d4d2dd5729cb94796aab2efc51b2c0485125 100644 (file)
@@ -19,14 +19,14 @@ $node_subscriber->start;
 $node_publisher->safe_psql('postgres',
    "CREATE TABLE tab_fk (bid int PRIMARY KEY);");
 $node_publisher->safe_psql('postgres',
-   "CREATE TABLE tab_fk_ref (id int PRIMARY KEY, bid int REFERENCES tab_fk (bid));"
+   "CREATE TABLE tab_fk_ref (id int PRIMARY KEY, junk text, bid int REFERENCES tab_fk (bid));"
 );
 
-# Setup structure on subscriber
+# Setup structure on subscriber; column order intentionally different
 $node_subscriber->safe_psql('postgres',
    "CREATE TABLE tab_fk (bid int PRIMARY KEY);");
 $node_subscriber->safe_psql('postgres',
-   "CREATE TABLE tab_fk_ref (id int PRIMARY KEY, bid int REFERENCES tab_fk (bid));"
+   "CREATE TABLE tab_fk_ref (id int PRIMARY KEY, bid int REFERENCES tab_fk (bid), junk text);"
 );
 
 # Setup logical replication
@@ -43,8 +43,10 @@ $node_publisher->wait_for_catchup($appname);
 
 $node_publisher->safe_psql('postgres',
    "INSERT INTO tab_fk (bid) VALUES (1);");
+# "junk" value is meant to be large enough to force out-of-line storage
 $node_publisher->safe_psql('postgres',
-   "INSERT INTO tab_fk_ref (id, bid) VALUES (1, 1);");
+   "INSERT INTO tab_fk_ref (id, bid, junk) VALUES (1, 1, repeat(pi()::text,20000));"
+);
 
 $node_publisher->wait_for_catchup($appname);
 
@@ -127,7 +129,8 @@ $node_publisher->wait_for_catchup($appname);
 
 $result = $node_subscriber->safe_psql('postgres',
    "SELECT count(*), min(id), max(id) FROM tab_fk_ref;");
-is($result, qq(2|1|2), 'check column trigger applied on even for other column');
+is($result, qq(2|1|2),
+   'check column trigger applied even on update for other column');
 
 $node_subscriber->stop('fast');
 $node_publisher->stop('fast');