Horton

Re: wake up logical workers after ALTER SUBSCRIPTION

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Melih Mutlu <m.melihmutlu@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2023-01-03T05:33:32Z
Lists: pgsql-hackers 
On Thu, Dec 15, 2022 at 4:47 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Wed, Dec 14, 2022 at 02:02:58PM -0500, Tom Lane wrote:
> > Maybe we could have workers that are exiting for that reason set a
> > flag saying "please restart me without delay"?
>
> That helps a bit, but there are still delays when starting workers for new
> subscriptions.  I think we'd need to create a new array in shared memory
> for subscription OIDs that need their workers started immediately.
>

That would be tricky because the list of subscription OIDs can be
longer than the workers. Can't we set a boolean variable
(check_immediate or something like that) in LogicalRepCtxStruct and
use that to traverse the subscriptions? So, when any worker will
restart because of a parameter change, we can set the variable and
send a signal to the launcher. The launcher can then check this
variable to decide whether to start the missing workers for enabled
subscriptions.

-- 
With Regards,
Amit Kapila.

Commits

  1. Avoid type cheats for invalid dsa_handles and dshash_table_handles.

  2. Track logrep apply workers' last start times to avoid useless waits.

  3. Check for two_phase change at end of process_syncing_tables_for_apply.

  4. Wake up a subscription's replication worker processes after DDL.