Re: wake up logical workers after ALTER SUBSCRIPTION

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>, 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-07T00:45:25Z
Lists: pgsql-hackers
On Fri, Jan 06, 2023 at 05:31:26PM -0500, Tom Lane wrote:
> I've pushed 0001 and 0002, which seem pretty uncontroversial.

Thanks!

> Attached is a rebased 0003, just to keep the cfbot happy.
> I'm kind of wondering whether 0003 is worth the complexity TBH,
> but in any case I ran out of time to look at it closely today.

Yeah.  It's not as bad as I was expecting, but it does add a bit more
complexity than is probably warranted.  I'm not wedded to this approach.

BTW I intend to start a new thread for the bugs I mentioned upthread that
were revealed by setting wal_retrieve_retry_interval to 1ms in the tests.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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.