Re: Logical Replication of sequences
От | vignesh C |
---|---|
Тема | Re: Logical Replication of sequences |
Дата | |
Msg-id | CALDaNm13K+AjnkLuSu++s_E+uYCZTiDS-8XE0MhwEte_GpSP6Q@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Logical Replication of sequences ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Logical Replication of sequences
|
Список | pgsql-hackers |
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
Вложения
- v20250818-0001-Enhance-pg_get_sequence_data-function.patch
- v20250818-0002-Introduce-ALL-SEQUENCES-support-for-Postgr.patch
- v20250818-0004-Introduce-REFRESH-PUBLICATION-SEQUENCES-fo.patch
- v20250818-0005-New-worker-for-sequence-synchronization-du.patch
- v20250818-0003-Reorganize-tablesync-Code-and-Introduce-sy.patch
- v20250818-0006-Documentation-for-sequence-synchronization.patch
В списке pgsql-hackers по дате отправления: