Re: Logical Replication of sequences
vignesh C <vignesh21@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
Attachments
- v20250818-0001-Enhance-pg_get_sequence_data-function.patch (application/octet-stream) patch v20250818-0001
- v20250818-0002-Introduce-ALL-SEQUENCES-support-for-Postgr.patch (application/octet-stream) patch v20250818-0002
- v20250818-0004-Introduce-REFRESH-PUBLICATION-SEQUENCES-fo.patch (application/octet-stream) patch v20250818-0004
- v20250818-0005-New-worker-for-sequence-synchronization-du.patch (application/octet-stream) patch v20250818-0005
- v20250818-0003-Reorganize-tablesync-Code-and-Introduce-sy.patch (application/octet-stream) patch v20250818-0003
- v20250818-0006-Documentation-for-sequence-synchronization.patch (application/octet-stream) patch v20250818-0006
On Fri, 15 Aug 2025 at 16:46, Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Vignesh,
>
> Thanks for updating the patch. Here are my small comments:
>
> 01.
> Per pgindent report, publicationcmds.c should be fixed.
Modified
> 02.
> ```
> + ScanKeyInit(&skey[1],
> + Anum_pg_subscription_rel_srsubstate,
> + BTEqualStrategyNumber, F_CHARNE,
> + CharGetDatum(SUBREL_STATE_READY));
> ```
>
> I felt it is more natural to "srsubstate = 'i'", instead of "srsubstate <> 'r'"
Modified
> 03.
> ```
> + table_close(sequence_rel, NoLock);
> + }
> +
> + /* Cleanup */
> + systable_endscan(scan);
> + table_close(rel, AccessShareLock);
> +
> + CommitTransactionCommand();
> ```
>
> To clarify, can we release the sequence at the end of the inner loop?
>
> I found that sequence relation is closed (but not release the lock) then commit
> the transaction once. This approach cannot avoid dropping it by concurrent
> transactions, but maybe you did due to the performance reason. So...I felt we
> may able to release bit earlier.
Modified
> 04.
> ```
> + sequence_rel = try_table_open(seqinfo->localrelid, RowExclusiveLock);
> +
> + /* Get the local sequence */
> + tup = SearchSysCache1(SEQRELID, ObjectIdGetDatum(seqinfo->localrelid));
> + if (!sequence_rel || !HeapTupleIsValid(tup))
> + {
> + elog(LOG, "skip synchronization of sequence \"%s.%s\" because it has been dropped concurrently",
> + seqinfo->nspname, seqinfo->seqname);
> +
> + batch_skipped_count++;
> + continue;
> + }
> ```
>
> a. Code comment can be atop try_table_open().
> b. Isn't it enough to check HeapTupleIsValid() here?
Modified
> 05.
> ```
> + /* Update the sequence only if the parameters are identical */
> + if (seqform->seqtypid == seqtypid &&
> + seqform->seqmin == seqmin && seqform->seqmax == seqmax &&
> + seqform->seqcycle == seqcycle &&
> + seqform->seqstart == seqstart &&
> + seqform->seqincrement == seqincrement)
> ```
>
> I noticed that seqcache is not compared. Is there a reason?
I felt we could go ahead and set the sequence value even if seqcache
is different unlike the other sequence parameters. That is the reason
I did not compare it. Thoughts?
> 06.
> ```
> + foreach_ptr(LogicalRepSequenceInfo, seq_info, sequences_to_copy)
> + {
> + pfree(seq_info->seqname);
> + pfree(seq_info->nspname);
> + pfree(seq_info);
> + }
> ```
>
> Per comment atop foreach_delete_current(), we should not directly do pfree()
> the entry. Can you use foreach_delete_current()? I.e.,
Modified
> 07.
> ```
> foreach_ptr(LogicalRepSequenceInfo, seq_info, sequences_to_copy)
> {
> pfree(seq_info->seqname);
> pfree(seq_info->nspname);
>
> sequences_to_copy =
> foreach_delete_current(sequences_to_copy, seq_info);
> }
> ```
Modified
> 08.
> ```
> +$node_subscriber->init(allows_streaming => 'logical');
> ```
>
> Actually no need to set to 'logical'.
Modified
Thanks for the comments, the updated version has the changes for the same.
Regards,
Vignesh