Re: Logical Replication of sequences - Mailing list pgsql-hackers

From vignesh C
Subject Re: Logical Replication of sequences
Date
Msg-id CALDaNm3hS58W0RTbgsMTk-YvXwt956uabA=kYfLGUs3uRNC2Qg@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication of sequences  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Logical Replication of sequences
Re: Logical Replication of sequences
List pgsql-hackers
On Mon, 12 Aug 2024 at 08:50, Peter Smith <smithpb2250@gmail.com> wrote:
>
> ~~~
>
> 3.
> I am not sure that it was an improvement to move the
> process_syncing_sequences_for_apply() function into the
> sequencesync.c. Calling the sequence code from the tablesync code
> still looks strange. OTOH, I see why you don't want to leave it in
> tablesync.c.
>
> Perhaps it would be better to refactor/move all following functions
> back to the (apply) worker.c instead:
> - process_syncing_relations
> - process_syncing_sequences_for_apply(void)
> - process_syncing_tables_for_apply(void)
>
> Actually, now that there are 2 kinds of 'sync' workers, maybe you
> should introduce a new module (e.g. 'commonsync.c' or
> 'syncworker.c...), where you can put functions such as
> process_syncing_relations() plus any other code common to both
> tablesync and sequencesync. That might make more sense then having one
> call to the other.

I created syncutils.c to consolidate code that supports worker
synchronization, table synchronization, and sequence synchronization.
While it may not align exactly with your suggestion, I included
functions like finish_sync_worker, invalidate_syncing_relation_states,
FetchRelationStates, and process_syncing_relations in this new file. I
believe this organization will make the code easier to review.

The rest of the comments are also fixed in the attached v20240812
version patch attached.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences