On Wed, Dec 17, 2025 at 12:37 PM Peter Smith wrote:
>
> Here is a completely different idea. This may solve the immediate
> problem re the replication of the Conflict Log Table (CLT) at least...
>
> 0. AFAIK, anything named with a "pg_" prefix generally means that the
> named thing is intended for
Hi,
Here is a completely different idea. This may solve the immediate
problem re the replication of the Conflict Log Table (CLT) at least...
0. AFAIK, anything named with a "pg_" prefix generally means that the
named thing is intended for PG internal use, right?
1. So, the CLT should be automati
On Wed, Dec 17, 2025 at 9:52 AM Andres Freund wrote:
>
> On 2025-12-17 09:19:57 +0530, Dilip Kumar wrote:
> > On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
> > > Actually, wouldn't a table-level property be completely inappropriate for
> > > that? Imagine one publication that's used for
Hi,
On 2025-12-17 09:19:57 +0530, Dilip Kumar wrote:
> On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
> > Actually, wouldn't a table-level property be completely inappropriate for
> > that? Imagine one publication that's used for HA (or major version upgrade)
> > and doesn't use a conflic
On Tue, Dec 16, 2025 at 11:15 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> > On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > > feature, we need a clean way to exclude these
On Tue, Dec 16, 2025 at 9:58 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > Motivation
> >
> > 1) The check is performed frequently in the logical decoding path
> > (e.g., in pgoutput_change and pgoutput_truncate). Moving this to a
> > cached cata
Hi,
On 2025-12-16 11:28:11 -0500, Andres Freund wrote:
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table
> > feature, we need a clean way to exclude these internal conflict log
> > tables from publication. A catalog flag a
Hi,
On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> Motivation
>
> 1) The check is performed frequently in the logical decoding path
> (e.g., in pgoutput_change and pgoutput_truncate). Moving this to a
> cached catalog attribute in pg_class allows for a simple check.
You could solve t
Hello hackers,
I would like to propose an improvement to the way PostgreSQL
determines if a relation is eligible for logical replication.
Currently, this check is performed dynamically via
is_publishable_class(), which relies on hard-coded OID checks and
relkind. As noted in the existing comments
