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 <sawada.mshk@gmail.com>

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: