RE: sequencesync worker race with REFRESH SEQUENCES - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: sequencesync worker race with REFRESH SEQUENCES
Date
Msg-id OS9PR01MB1214922AE07732C4592D1AB5EF5CF2@OS9PR01MB12149.jpnprd01.prod.outlook.com
Whole thread
In response to Re: sequencesync worker race with REFRESH SEQUENCES  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
Dear Vignesh,

> a) Finding 9: A running sequence synchronization worker continues
> processing after ALTER SUBSCRIPTION ... DISABLE.  In this case the
> leader apply worker only terminated its parallel apply workers on
> detach, so a running sequencesync worker could outlive a DISABLE.
> logicalrep_worker_detach() now also stops the sequencesync worker.

Hmm, but tablesync workers, which can connect to the publisher by itself are not
terminated by the function. IIUC, tablesync workers can read the subscription
catalog and recognize the catalog. I feel we should follow that approach.

Note: I cannot find the place sequencesync worker calls maybe_reread_subscription().
It might mean that the worker cannot recognize alternations of the subscription.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

pgsql-hackers by date:

Previous
From: Henson Choi
Date:
Subject: Re: [PATCH] Fix quotation logic for unreserved keywords in window specifications
Next
From: Xuneng Zhou
Date:
Subject: Re: BUG: ReadStream look-ahead exhausts local buffers when effective_io_concurrency>=64