| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Subject: | Re: Logical Replication of sequences |
| Date: | 2024-08-12 13:06:26 |
| Message-ID: | CALDaNm3hS58W0RTbgsMTk-YvXwt956uabA=kYfLGUs3uRNC2Qg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 12 Aug 2024 at 08:50, Peter Smith <smithpb2250(at)gmail(dot)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 | Content-Type | Size |
|---|---|---|
| v20240812-0003-Reorganization-of-tablesync-code.patch | text/x-patch | 13.7 KB |
| v20240812-0004-Enhance-sequence-synchronization-during-su.patch | text/x-patch | 92.6 KB |
| v20240812-0002-Introduce-ALL-SEQUENCES-support-for-Postgr.patch | text/x-patch | 90.4 KB |
| v20240812-0001-Introduce-pg_sequence_state-function-for-e.patch | text/x-patch | 11.4 KB |
| v20240812-0005-Documentation-for-sequence-synchronization.patch | text/x-patch | 24.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2024-08-12 13:07:21 | Re: Logical Replication of sequences |
| Previous Message | Amit Langote | 2024-08-12 12:54:16 | Re: generic plans and "initial" pruning |