Improve tablesync behavior with concurrent changes

When a table is removed from a subscription before the tablesync worker
could start, this would previously result in an error when reading
pg_subscription_rel.  Now we just ignore this.

Author: Masahiko Sawada <[email protected]>

diff --git a/src/backend/replication/logical/tablesync.c b/src/backend/replication/logical/tablesync.c
index f57ae6ee2d560abc048abad2b7b345aff600c955..7bfb7b1052ca83f76b89c76e9d6c242df379e957 100644 (file)
--- a/src/backend/replication/logical/tablesync.c
+++ b/src/backend/replication/logical/tablesync.c
@@ -796,7 +796,7 @@ LogicalRepSyncTableStart(XLogRecPtr *origin_startpos)
    StartTransactionCommand();
    relstate = GetSubscriptionRelState(MyLogicalRepWorker->subid,
                                       MyLogicalRepWorker->relid,
-                                      &relstate_lsn, false);
+                                      &relstate_lsn, true);
    CommitTransactionCommand();
 
    SpinLockAcquire(&MyLogicalRepWorker->relmutex);
@@ -942,7 +942,10 @@ LogicalRepSyncTableStart(XLogRecPtr *origin_startpos)
            }
        case SUBREL_STATE_SYNCDONE:
        case SUBREL_STATE_READY:
-           /* Nothing to do here but finish. */
+       case SUBREL_STATE_UNKNOWN:
+           /* Nothing to do here but finish.  (UNKNOWN means the relation was
+            * removed from pg_subscription_rel before the sync worker could
+            * start.) */
            finish_sync_worker();
            break;
        default: