On Fri, 7 Nov 2025 at 20:18, vignesh C <[email protected]> wrote: > > On Fri, 7 Nov 2025 at 14:54, shveta malik <[email protected]> wrote: > > > > On Fri, Nov 7, 2025 at 10:58 AM vignesh C <[email protected]> wrote: > > > > > > > > > Thanks for pushing the patch, here is a rebased version of the > > > remaining patches. > > > > > > > Please find a few comments on doc patch: > > > > 1) > > + them. To verify this, compare the > > + <link > > linkend="catalog-pg-subscription-rel">pg_subscription_rel</link>.<structfield>srsublsn</structfield> > > + on the subscriber with the page_lsn obtained from the > > + <function>pg_get_sequence_data</function> for the sequence on the > > publisher. > > > > Is there a way to give link of 'pg_get_sequence_data' here? > > Modified > > > 2) > > + <warning> > > + <para> > > + Each sequence caches a block of values (typically 32) in memory before > > + generating a new WAL record, so its LSN advances only after the entire > > + cached batch has been consumed. As a result, sequence value > > drift cannot be > > + detected by comparing LSNs for sequence increments that fall within > > the > > + same cached block. > > + </para> > > + </warning> > > > > In such a case, shall we mention that compare last_value to see the > > drift? Thoughts? > > I was not sure as it might not be very efficient > > > 3) > > > > + To detect this, compare the > > + <link > > linkend="catalog-pg-subscription-rel">pg_subscription_rel</link>.<structfield>srsublsn</structfield> > > + on the subscriber with the page_lsn obtained from the > > + <function>pg_get_sequence_data</function> for the sequence on the > > publisher. > > > > > > We have mentioned above. But in the example of the same, we do not > > show srsublsn or page_lsn anywhere. Shall we query and show that as > > well? > > Updated example > > > > > 4) > > Maximum number of synchronization workers per subscription. This > > parameter controls the amount of parallelism of the initial data > > copy > > during the subscription initialization or when new tables are > > added. > > + One additional worker is also needed for sequence synchronization. > > </para> > > > > Since now the first line is talking only about table-sync, shall we tweak > > it: > > 'of the initial data copy' --> 'of the initial data copy for tables' > > Modified > > > 5) > > + Returns information about the sequence. > > <literal>last_value</literal> > > + indicates last sequence value set in sequence by nextval or setval, > > > > last_value can also be set by seq synchronization. Do you think that > > we need to mention that or current info is good enough? > > Updated > > The attached v20251107_2 version patch has the changes for the same. > Hi Vignesh,
While working on another thread, I found that in HEAD gram.y has
grammar which was committed as part of this thread:
```
| CREATE PUBLICATION name FOR pub_obj_type_list opt_definition
{
CreatePublicationStmt *n = makeNode(CreatePublicationStmt);
n->pubname = $3;
n->pubobjects = (List *) $5;
preprocess_pub_all_objtype_list($5, &n->for_all_tables,
&n->for_all_sequences,
yyscanner);
n->options = $6;
$$ = (Node *) n;
}
```
Here we are assigning "n->pubobjects = (List *) $5". But later in the
code this is not used anywhere for ALL TABLES/ ALL SEQUENCES
publication. It is used for other publications (not ALL TABLES/
SEQUENCES) inside function "ObjectsInPublicationToOids"
So are we required to assign "n->pubobjects" here?
I have created a patch to remove this assignment. It passed "make check-world".
Thanks,
Shlok Kyal
v1-0001-Remove-unused-n-pubobjects-assignment-for-CREATE-.patch
Description: Binary data
