Re: Logical Replication of sequences
shveta malik <shveta.malik@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, Dec 18, 2025 at 5:30 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Thu, 18 Dec 2025 at 17:03, shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Thu, Dec 18, 2025 at 3:04 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > On Thu, 18 Dec 2025 at 12:37, Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
> > > >
> > > > Hi Team,
> > > >
> > > > While working on another thread, I noticed a bug introduced by commit
> > > > as part of this thread.
> > > > In function pg_get_publication_tables, We have code:
> > > > ```
> > > > if (pub_elem->alltables)
> > > > pub_elem_tables = GetAllPublicationRelations(RELKIND_RELATION,
> > > > pub_elem->pubviaroot);
> > > > else
> > > > {
> > > > List *relids,
> > > > *schemarelids;
> > > >
> > > > relids = GetPublicationRelations(pub_elem->oid,
> > > > pub_elem->pubviaroot ?
> > > > PUBLICATION_PART_ROOT :
> > > > PUBLICATION_PART_LEAF);
> > > > schemarelids = GetAllSchemaPublicationRelations(pub_elem->oid,
> > > > pub_elem->pubviaroot ?
> > > > PUBLICATION_PART_ROOT :
> > > > PUBLICATION_PART_LEAF);
> > > > pub_elem_tables = list_concat_unique_oid(relids, schemarelids);
> > > > }
> > > > ```
> > > >
> > > > So, when we create an 'ALL SEQUENCE publication' and we execute
> > > > 'SELECT * from pg_publication_tables'
> > > > We will enter the else condition in the above code, which does not
> > > > seem correct to me.
> > > > It will call functions which are not required to be called. It will
> > > > also call the function 'GetPublicationRelations' which contradicts the
> > > > comment above this function.
> > > >
> > > > Similar issue is present for functions "InvalidatePubRelSyncCache" and
> > > > "AlterPublicationOptions".
> > >
> > > Thanks Shlok for reporting these issues, In the areas highlighted, we
> > > can skip processing for sequences-only publications. The attached
> > > patch implements these changes.
> > >
> >
> > We have '!pub->alltables' check at 2 more places:
> > -- pgoutput_row_filter_init()
>
> It's not necessary here, because only publications that actually
> replicate the given relation are passed to pgoutput_row_filter_init.
> Sequence publications are excluded from this list, so they will never
> appear there.
>
> > -- pg_get_publication_tables()
>
> We don't need to explicitly check !pub->allsequences here. The guard
> if (funcctx->call_cntr < list_length(table_infos))
> already ensures that the remaining code is executed only when
> table_infos contains elements. If the list has entries, it necessarily
> represents a table publication, and it will enumerate those tables. If
> the list is empty, the condition fails and no rows are returned, so
> the extra check is not required.
>
Okay, the patch LGTM.
thanks
Shveta