| From: | vignesh C <vignesh21(at)gmail(dot)com> | 
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> | 
| Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Euler Taveira <euler(at)eulerto(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> | 
| Subject: | Re: Logical Replication of sequences | 
| Date: | 2025-11-03 15:16:10 | 
| Message-ID: | CALDaNm2wdoV4SZNx6vk=2XZK_r90JB-W5G4GSOMuELBqb9jy2w@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, 3 Nov 2025 at 16:44, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Nov 3, 2025 at 12:35 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
>
> Some inor comments on 0001.
> 1.
> + /*
> + * Acquire LogicalRepWorkerLock in LW_EXCLUSIVE mode to block the apply
> + * worker (holding LW_SHARED) from reading or updating
> + * last_seqsync_start_time. See ProcessSyncingSequencesForApply().
> + */
> + LWLockAcquire(LogicalRepWorkerLock, LW_EXCLUSIVE);
>
> Is it required to have LW_EXCLUSIVE lock here? In the function
> ProcessSyncingSequencesForApply(), apply_worker access/update
> last_seqsync_start_time only once it ensures that sequence sync worker
> has exited. I have made changes related to this in the attached to
> show you what I have in mind.
Modified
> 2.
> + /*
> + * Worker needs to process sequences across transaction boundary, so
> + * allocate them under long-lived context.
> + */
> + oldctx = MemoryContextSwitchTo(TopMemoryContext);
> +
> + seq = palloc0_object(LogicalRepSequenceInfo);
> …
> ...
> + /*
> + * Allocate in a long-lived memory context, since these
> + * errors will be reported after the transaction commits.
> + */
> + oldctx = MemoryContextSwitchTo(TopMemoryContext);
> + mismatched_seqs = lappend_int(mismatched_seqs, seqidx);
>
> At the above and other places in syncworker, we don't need to use
> TopMemoryContext; rather, we can use ApplyContext allocated via
> SequenceSyncWorkerMain()->SetupApplyOrSyncWorker()->InitializeLogRepWorker().
Modified
> 3.
> ProcessSyncingTablesForApply(current_lsn);
> + ProcessSyncingSequencesForApply();
>
> I am not sure if the function name ProcessSyncingSequencesForApply is
> appropriate. For tables, we do some work for concurrently running
> tablesync workers and launch new as well but for sequences, we don't
> do any work for sequences that are already being synced. How about
> ProcessSequencesForSync()?
Changed it to ProcessSequencesForSync
> 4.
> +      /* Should never happen. */
> +      elog(ERROR, "Sequence synchronization worker not expected to
> process relations");
>
> The first letter of the ERROR message should be small. How about:
> "sequence synchronization worker is not expected to process
> relations"? I have made this change in the attached.
Modified
> 5.
> @@ -5580,7 +5606,8 @@ start_apply(XLogRecPtr origin_startpos)
> * idle state.
> */
> AbortOutOfAnyTransaction();
> - pgstat_report_subscription_error(MySubscription->oid, !am_tablesync_worker());
> + pgstat_report_subscription_error(MySubscription->oid,
> + !am_tablesync_worker());
>
> Why this change?
This is not required, removed this change
> 6.
> @@ -264,6 +267,8 @@ extern bool
> logicalrep_worker_launch(LogicalRepWorkerType wtype,
> Oid userid, Oid relid,
> dsm_handle subworker_dsm,
> bool retain_dead_tuples);
> +extern void launch_sync_worker(LogicalRepWorkerType wtype, int nsyncworkers,
> +    Oid relid, TimestampTz *last_start_time);
> extern void logicalrep_worker_stop(LogicalRepWorkerType wtype, Oid subid,
>    Oid relid);
> All the other functions except the newly added one are from
> launcher.c. So, this one should be after those, no? It should be after
> the InvalidateSyncingRelStates() declaration.
Modified
> Apart from above, please find attached top-up patch to improve
> comments and some other cosmetic stuff.
Thanks, I have merged them.
The attached v20251103 patch has the changes for the same.
Regards,
Vignesh
| Attachment | Content-Type | Size | 
|---|---|---|
| v20251103-0001-Add-sequence-synchronization-for-logical-r.patch | text/x-patch | 66.5 KB | 
| v20251103-0003-Add-seq_sync_error_count-to-subscription-s.patch | text/x-patch | 21.6 KB | 
| v20251103-0002-Documentation-for-sequence-synchronization.patch | text/x-patch | 20.5 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-11-03 15:19:18 | Re: [PATCH] Fix orphaned backend processes on Windows using Job Objects | 
| Previous Message | Andres Freund | 2025-11-03 15:13:02 | Re: Implement waiting for wal lsn replay: reloaded |