From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(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>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Subject: | Re: Logical Replication of sequences |
Date: | 2025-09-02 13:42:00 |
Message-ID: | CALDaNm20qooAJP3qHXHDm=TPVxXoY-iUcD6RdaTSVUd2jcV+7w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 28 Aug 2025 at 17:08, Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Vignesh,
>
> Thanks for updating the patch. Below are my comments.
>
> 01.
> ```
> /* Relation is either a sequence or a table */
> relkind = get_rel_relkind(subrel->srrelid);
> if (relkind != RELKIND_SEQUENCE)
> continue;
> ```
>
> Can you update the comment to "Skip if the relation is not a sequence"?
> The current one seems not related with what we do.
Modified
> 02.
> ```
> appendStringInfo(&app_name, "%s_%s", MySubscription->name, "sequencesync worker");
> ```
>
> I'm wondering what is the good application_name. One idea is to follow the
> tablesync worker: "pg_%u_sequence_sync_%u_%llu", another one is to use the same
> name as bgwoker: "logical replication sequencesync worker for subscription %u".
> Your name is also valid but it looks quite different with other processes.
> Do others have any opinions?
Modified
> 03.
> ```
> test_pub=# SELECT NEXTVAL('s1');
> ```
> I feel no need to be capital.
Modified
> 04.
> ```
> <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link> or
> <link linkend="sql-altersubscription-params-refresh-publication">
> <command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command></link> or
> <link linkend="sql-altersubscription-params-refresh-publication-sequences">
> <command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION SEQUENCES</command></link>.
> ```
>
> IIUC, we can use "A, B, or C" style.
Modified
> 05.
> ```
> + In logical replication, this parameter also limits how quickly a
> + failing replication apply worker or table synchronization worker or
> + sequence synchronization worker will be respawned.
> ```
>
> Same as above.
Modified
> 06.
> ```
> <para>
> State codes for sequences:
> <literal>i</literal> = initialize,
> <literal>r</literal> = ready
> </para></entry>
> ```
>
> Now the attribute can be "d".
Modified
> 07.
>
> I feel we should add notes for subscription options. e.g., binary option
> is no-op for sequence sync.
Modified
> 08.
> ```
> /* Get the list of tables and sequences from the publisher. */
> if (server_version >= 190000)
> {
> ```
>
> Not sure which is better, but I considered a way to append the string atop v16.
> Please see attached. How do you feel?
Modified
> 09.
> fetch_relation_list() still has some "tables", which should be "relations".
Modified
> 10.
> ```
> if (sequencesync_worker)
> {
> /* Now safe to release the LWLock */
> LWLockRelease(LogicalRepWorkerLock);
> return;
> }
> ```
>
> Not sure the comment is needed because the lock is acquired just above. Instead
> we can describe that sequence sync worker exists up to one per a subscription.
Removed this comment. I felt no need to add any additional comments here.
> 11.
> Currently copy_sequences() does not check privilege within the function, it is
> done in SetSequence(). Basically it works well, but if the user does not have
> enough privilege, for one of the sequence in the batch, ERROR would be
> raised - all sequences cannot be synched. How about detecting it in the loop
> and skip synchronizing? This allows other sequences to be synced.
Currently we have missing sequences and mismatched sequences being
printed at the end of the batch. We print the skip sequence because it
is dropped concurrently or altered concurrently in the loop. Should we
include this also in the loop itself? Based on it, I will change in
next version.
> 12.
> ```
> /*
> * This is a clean exit of the sequencesync worker; reset the
> * last_seqsync_start_time.
> */
> logicalrep_reset_seqsync_start_time();
> ```
>
> ISTM the function can be used both sequence and table sync worker.
It is not required for table sync worker, for table sync worker it is
maintained in last_start_times hash table.
> 13.
> ```
> /* Fetch tables and sequences that are in non-ready state. */
> rstates = GetSubscriptionRelations(MySubscription->oid, true, true,
> true);
> ```
>
> IIUC no need to check sequences if has_pending_sequences is NULL.
I feel it is required, this is required to determine if a sequence
sync worker should be started or not.
Thanks for the comments, the attached patch has the changes for the same.
Regards,
Vignesh
Attachment | Content-Type | Size |
---|---|---|
v20250902-0001-Enhance-pg_get_sequence_data-function.patch | text/x-patch | 7.4 KB |
v20250902-0004-Update-ALTER-SUBSCRIPTION-REFRESH-to-ALTER.patch | text/x-patch | 8.9 KB |
v20250902-0002-Introduce-ALL-SEQUENCES-support-for-Postgr.patch | text/x-patch | 110.7 KB |
v20250902-0005-Introduce-REFRESH-PUBLICATION-SEQUENCES-fo.patch | text/x-patch | 40.0 KB |
v20250902-0003-Reorganize-tablesync-Code-and-Introduce-sy.patch | text/x-patch | 24.6 KB |
v20250902-0006-New-worker-for-sequence-synchronization-du.patch | text/x-patch | 88.7 KB |
v20250902-0007-Documentation-for-sequence-synchronization.patch | text/x-patch | 35.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-09-02 14:43:40 | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
Previous Message | Robert Haas | 2025-09-02 13:35:45 | Re: Extension security improvement: Add support for extensions with an owned schema |