Re: wake up logical workers after ALTER SUBSCRIPTION

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
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-22T19:12:54Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Jan 10, 2023 at 10:59:14AM +0530, Amit Kapila wrote:
>> I haven't looked in detail but isn't it better to explain somewhere in
>> the comments that it achieves to rate limit the restart of workers in
>> case of error and allows them to restart immediately in case of
>> subscription parameter change?

> I expanded one of the existing comments to make this clear.

I pushed v17 with some mostly-cosmetic changes, including more comments.

> Of course, if the launcher restarts, then the notify_pid will no longer be
> accurate.  However, I see that workers also register a before_shmem_exit
> callback that will send SIGUSR1 to the launcher_pid currently stored in
> shared memory.  (I wonder if there is a memory ordering bug here.)

I think it's all close enough in reality.  There are other issues in
this code, and I'm about to start a new thread about one I identified
while testing this patch, but I think we're in good shape on this
particular point.  I've marked the CF entry as committed.

			regards, tom lane



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.