Horton

Re: Logical Replication of sequences

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>, shveta malik <shveta.malik@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2025-09-04T21:34:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Doc: Add documentation for sequence synchronization.

  2. Remove unused assignment in CREATE PUBLICATION grammar.

  3. Add seq_sync_error_count to subscription statistics.

  4. Fix few issues in commit 5509055d69.

  5. Add sequence synchronization for logical replication.

  6. Add worker type argument to logical replication worker functions.

  7. Introduce "REFRESH SEQUENCES" for subscriptions.

  8. Refactor logical worker synchronization code into a separate file.

  9. Standardize use of REFRESH PUBLICATION in code and messages.

  10. Add "ALL SEQUENCES" support to publications.

  11. Expose sequence page LSN via pg_get_sequence_data.

  12. Resume conflict-relevant data retention automatically.

  13. Post-commit review fixes for 228c370868.

  14. Generate GUC tables from .dat file

On Thu, Sep 4, 2025 at 9:51 AM vignesh C <vignesh21@gmail.com> wrote:
>
> On Wed, 3 Sept 2025 at 13:04, Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > Dear Vignesh,
> >
> > Thanks for updating the patch. Few comments:
> > 01.
> > ```
> >         /* Find the leader apply worker and signal it. */
> >         logicalrep_worker_wakeup(MyLogicalRepWorker->subid, InvalidOid);
> > ```
> >
> > Sequencesync worker does not need to send a signal to the apply worker.
> > Should we skip in the case?
> > Per my understanding, the signal is being used to set the status to STATE_READY.
>
> Modified
>
> > 02.
> > ```
> >         if (worker)
> >                 worker->last_seqsync_start_time = 0;
> >
> >         LWLockRelease(LogicalRepWorkerLock);
> > ```
> >
> > I feel we can release LWLock first then update last_seqsync_start_time.
>
> I felt it should be done within lock so that
> ProcessSyncingSequencesForApply waits till the last_seqsync_start_time
> is also set.
>
> > 03.
> > Sequencesync worker cannot update its GUC parameters because ProcessConfigFile()
> > is not called. How about checking the signal at the end of batch loop?
>
> Modified
>
> > 04.
> > ```
> >                         while (search_pos < total_seqs)
> >                         {
> >                                 LogicalRepSequenceInfo *candidate_seq = lfirst(list_nth_cell(sequences_to_copy, search_pos));
> >
> >                                 if (!strcmp(candidate_seq->nspname, nspname) &&
> >                                         !strcmp(candidate_seq->seqname, seqname))
> >                                 {
> >                                         seqinfo = candidate_seq;
> >                                         search_pos++;
> >                                         break;
> >                                 }
> >
> >                                 search_pos++;
> >                         }
> > ```
> >
> > It looks like that if the entry in sequences_to_copy is skipped, it won't be
> > referred anymore. I feel this is method is bit dangerous, because ordering of
> > the list may be different with the returned tuples from the publisher. Nodes may
> > use the different collations.
>
> Modified
>
> The attached patch has the changes for the same.

Please rebase the patches as they conflict with current HEAD (due to
commit 6359989654).

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com