From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Report replica identity in pg_publication_tables |
Date: | 2025-07-02 08:16:01 |
Message-ID: | TYAPR01MB57244DD0DC539E60FA03A2189440A@TYAPR01MB5724.jpnprd01.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 30, 2025 at 8:09 PM Ashutosh Bapat wrote:
>
> On Mon, Jun 30, 2025 at 5:17 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >
> > On Mon, Jun 30, 2025 at 3:44 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> >
> > > Given a set of publications that a WAL sender is using,
> > > pg_publication_tables can be used to get the list of tables whose
> > > changes will be replicated including the columns of those tables
> > > and row filters. But the replica identity of those tables needs to
> > > be separately found out by querying pg_class or joining pg_class
> > > with pg_publication_tables on schemaname and relname. Adding the
> > > replica identity column to pg_publication_tables avoids this extra step.
> > >
> > > The replica identity of a given table is not a property of
> > > publication, per say, so it's arguable whether it should be
> > > included in pg_publication_tables or not.
> > >
> >
> > Right, discussing the use case a bit more might help us to find if
> > this is the right place to add 'replica identity' information.
>
> In our case, we had multiple replication slots, each with a different publication.
> One of the slots was lagging because of the amount of data being sent
> through the slot. For that we wanted to know which tables are being
> published through the corresponding publication and what's the replica
> identity of each of the tables.
> pg_publication_tables gave us the list of tables but in order to get
> its replica identity we needed to join it with pg_class again.
> pg_publication_tables already joins pg_class. Exposing replica
> identity through pg_publication_tables makes it more convenient to get
> all the information related to a tables replication through that
> publication in a single line without much code change or run time cost.
Thanks for explaining the use case.
I'm concerned about whether we can correctly display replica identity in the
view for partitioned tables.
In the case of partitioned tables, we display only the root table in the view
if publish_via_partition_root is enabled for the publication. However, the
logged information depends on the replica identity (RI) of each child
partition. Displaying only the root table's RI could be a bit confusing since
each partition might have different RI settings, making it challenging to
represent all of them in the entry for the root table.
Best Regards,
Hou zj
From | Date | Subject | |
---|---|---|---|
Next Message | Eduard Stefes | 2025-07-02 08:27:46 | RE: [V2] Adding new CRC32C implementation for IBM S390X |
Previous Message | Bertrand Drouvot | 2025-07-02 08:06:34 | Re: Fix inconsistency in the pg_buffercache documentation |