From 8dc7c338129d22a52d4afcf2f83a73041119efda Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 9 Jun 2017 09:20:54 -0400 Subject: [PATCH] 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 --- src/backend/replication/logical/tablesync.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/backend/replication/logical/tablesync.c b/src/backend/replication/logical/tablesync.c index f57ae6ee2d..7bfb7b1052 100644 --- 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: -- 2.49.0