Horton
Menu

Re: Proposal: Conflict log history table for Logical Replication

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2026-01-06T03:21:10Z
Lists: pgsql-hackers 
I was checking patch006. I understand the purpose of patch 006, but I
don’t think it’s needed at the moment. Currently, we support only two
destinations: log and table, and we already provide 'all' to cover
both. This patch would make sense if we either supported at least
three destinations or didn’t have the 'all' option. As it stands, none
of the comma-separated combinations are meaningful:

log,all
table,all
log,table (already covered by all)

Should we defer this patch until we actually support additional
destinations? One option is to remove 'all', but for now, 'all' feels
more appropriate than introducing comma-separated values.

thanks
Shveta

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow logical replication conflicts to be logged to a table.

  2. Avoid orphaned objects dependencies