Re: wake up logical workers after ALTER SUBSCRIPTION - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: wake up logical workers after ALTER SUBSCRIPTION
Date
Msg-id CAGPVpCTUuKyxB5f3exgDMBRTivbN5uHVkD=YfXmgznrdnwVOQw@mail.gmail.com
Whole thread Raw
In response to Re: wake up logical workers after ALTER SUBSCRIPTION  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: wake up logical workers after ALTER SUBSCRIPTION  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
Hi Nathan,

@@ -410,6 +411,12 @@ ExecRenameStmt(RenameStmt *stmt)
    stmt->newname);
  table_close(catalog, RowExclusiveLock);
 
+ /*
+ * Wake up the logical replication workers to handle this
+ * change quickly.
+ */
+ LogicalRepWorkersWakeupAtCommit(address.objectId);

Is it really necessary to wake logical workers up when renaming other than subscription or publication? address.objectId will be a valid subid only when renaming a subscription.

@@ -322,6 +323,9 @@ UpdateSubscriptionRelState(Oid subid, Oid relid, char state,
 
  /* Cleanup. */
  table_close(rel, NoLock);
+
+ /* Wake up the logical replication workers to handle this change quickly. */
+ LogicalRepWorkersWakeupAtCommit(subid);
 
I wonder why a wakeup call is needed every time a subscription relation is updated.
It seems to me that there are two places where UpdateSubscriptionRelState is called and we need another worker to wake up:
- When a relation is in SYNCWAIT state, it waits for the apply worker to wake up and change the relation state to CATCHUP. Then tablesync worker needs to wake up to continue from CATCHUP state.
- When the state is SYNCDONE and the apply worker has to wake up to change the state to READY.

I think we already call logicalrep_worker_wakeup_ptr wherever it's needed for the above cases? What am I missing here?

Best,
--
Melih Mutlu
Microsoft

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error-safe user functions
Next
From: Robert Haas
Date:
Subject: Re: Error-safe user functions