Re: Proposal: Conflict log history table for Logical Replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, shveta malik <shveta.malik@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-16T04:50:52Z
Lists: pgsql-hackers
On Tue, Jun 16, 2026 at 9:56 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Tue, Jun 16, 2026 at 9:27 AM vignesh C <vignesh21@gmail.com> wrote: > > > > Shouldn’t creating a view also be allowed for the same reason? > > > > The function is permitted because it only performs a SELECT on the > > conflict log table, and such read operations are allowed. A view > > likewise represents a stored query definition and does not modify the > > conflict schema or its underlying tables. Given that direct queries on > > the conflict log tables are already permitted, allowing users to > > define views over them is consistent with the same rationale applied > > to functions. > > Whats is the behavior of toast table w.r.t the function vs view? > I think sticking to the minimum set of commands that are required for the user to monitor/maintain CLT should be a good goal for the first version. We can evaluate to allow other commands based on real user need and its impact on the functionality. So, it is okay to block even the view on CLT for now. -- With Regards, Amit Kapila.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical replication conflicts to be logged to a table.
- a5918fddf10d master landed
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) cited