Re: Logical Replication of sequences
Peter Smith <smithpb2250@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Add documentation for sequence synchronization.
- 55cefadde874 19 (unreleased) landed
-
Remove unused assignment in CREATE PUBLICATION grammar.
- bfb7419b0bbe 19 (unreleased) landed
-
Add seq_sync_error_count to subscription statistics.
- f6a4c498dcf6 19 (unreleased) landed
-
Fix few issues in commit 5509055d69.
- 5a4eba558aa7 19 (unreleased) landed
-
Add sequence synchronization for logical replication.
- 5509055d6956 19 (unreleased) landed
-
Add worker type argument to logical replication worker functions.
- 3e8e05596a02 19 (unreleased) landed
-
Introduce "REFRESH SEQUENCES" for subscriptions.
- f0b3573c3aac 19 (unreleased) landed
-
Refactor logical worker synchronization code into a separate file.
- 41c674d2e31e 19 (unreleased) landed
-
Standardize use of REFRESH PUBLICATION in code and messages.
- 2436b8c047ff 19 (unreleased) landed
-
Add "ALL SEQUENCES" support to publications.
- 96b378497346 19 (unreleased) landed
-
Expose sequence page LSN via pg_get_sequence_data.
- b93172ca59f4 19 (unreleased) landed
-
Resume conflict-relevant data retention automatically.
- 0d48d393d465 19 (unreleased) cited
-
Post-commit review fixes for 228c370868.
- 1f7e9ba3ac4e 19 (unreleased) cited
-
Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
On Thu, Oct 9, 2025 at 5:32 PM shveta malik <shveta.malik@gmail.com> wrote: > > On Thu, Oct 9, 2025 at 11:32 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Oct 9, 2025 at 11:27 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > On Thu, Oct 9, 2025 at 10:14 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > > > On Wed, Oct 8, 2025 at 9:13 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > > > > On Tue, Oct 7, 2025 at 5:46 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > > > > > > > > > > > > > I have one more question: while testing the sequence sync, I found > > > > > > > this behavior is documented as well[1], but what's the reasoning > > > > > > > behind it? Why REFRESH PUBLICATION will synchronize only newly added > > > > > > > sequences and need to use REFRESH PUBLICATION SEQUENCES to > > > > > > > re-synchronize all sequences. > > > > > > > > > > > > > > > > > > > The idea is that REFRESH PUBLICATION should behave similarly for > > > > > > tables and sequences. This means that this command is primarily used > > > > > > to add/remove tables/sequences and copy their respective initial > > > > > > contents. The new command REFRESH PUBLICATION SEQUENCES is to sync the > > > > > > existing sequences, it shouldn't add any new sequences, now, if it is > > > > > > too confusing we can discuss having a different syntax for it. > > > > > > > > > > Sure, let's discuss this when we get this patch at the start of the > > > > > commit queue. > > > > > > > > > > > > > I have pushed the publications related patch. Now, we can discuss this > > > > command. I think confusion arises from the fact that both commands use > > > > REFRESH. > > > > > > Right > > > > > > So, how about for the second case (sync/copy all existing > > > > sequences), we use a different command, some ideas that come to my > > > > mind are: > > > > > > > > Alter Subscription sub1 REPLICATE Publication Sequences; > > > > Alter Subscription sub1 RESYNC Publication Sequences; > > > > Alter Subscription sub1 SYNC Publication Sequences; > > > > Alter Subscription sub1 MERGE Publication Sequences; > > > > > > > > Among these, the first three require a new keyword to be introduced. I > > > > prefer to use existing keyword if possible. Any ideas? > > > > > > I would have preferred "Alter Subscription sub1 SYNC Publication > > > Sequences" but if your preference is to use existing keywords then > > > IMHO "MERGE Publication Sequences" or "UPDATE Publication Sequences" > > > are also good options. > > > > > > > I would prefer "COPY Publication Sequences" or "UPDATE Publication > > Sequences" among the given options. We have a precedence for copy > > (copy_data) in publication command parameters, so, COPY could be a > > better option. > > > > If not SYNC, then COPY looks the next best option to me. > Something about all these ideas seems strange to me: I think the "ALTER SUBSCRIPTION sub REFRESH PUBLICATION" command has the word PUBLICATION in it because it's the PUBLICATION has changed (stuff added/removed), so we need to refresh it. OTOH, the synchronisation of *existing* sequences is different - this is more like the subscription saying "Just get me updated values for the sequences I already know about". Therefore, I don't think the word PUBLICATION is relevant here. ~~ So my suggestion is very different. Just this: "ALTER SUBSCRIPTION sub REFRESH SEQUENCES" I feel this is entirely consistent, because: PUBLICATION objects have changed. Refresh me the new objects => ALTER SUBSCRIPTION sub REFRESH PUBLICATION; SEQUENCE values have changed. Refresh me the new values => ALTER SUBSCRIPTION sub REFRESH SEQUENCES; ====== Kind Regards, Peter Smith. Fujitsu Australia