Re: Proposal: Conflict log history table for Logical Replication

On Thu, Jan 29, 2026 at 4:46 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> Dilip, I was testing patch002, few observations:
>
> 1)
> remote_commit_ts is '2026-01-29 14:38:02.777599+05:30' while
> local_conflicts.commit_ts is of format
> '2026-01-29T14:37:35.805819+05:30' i.e. a 'T' to separate date and
> time in local-commit_ts case. IIUC, this is the expected (standard)
> way for timestamps to be in json-format. Can you please confirm?

Yes, I will check that and respond.

> 2)
> Differences between LOG and TABLE:
>
> a) In LOG, the column names are not included in the remote or local
> tuples, whereas in the TABLE, they are. For example:
>
> LOG: Could not apply remote change: remote row (2, 3, 4)
> TABLE: remote_tuple: {"a":2,"b":3,"c":4}
> b) remote_commit_ts is not recorded in LOG, but it is included in the TABLE.
>
> IMO, both of these differences are okay as TABLE is expected to store
> (or can store) more detailed information. I’m just noting these here
> for others’ input. Let me know your thoughts.

Yeah, I think we do need additional data for table e.g. column name in
tuple so that users can use queries to extract value for specific
columns etc.

> 3)
> If we look at the table overall, the name 'local_conflicts' can be a
> bit misleading. This column actually stores the details about local
> rows involved in a conflict, rather than describing the conflict
> itself. See example below. A clearer name might be local_data,
> local_tuples_data, or local_tuples_detail. Thoughts?
>
> local_conflicts for one update_exists:
> {"{\"xid\":\"791\",\"commit_ts\":\"2026-01-29T14:37:35.805819+05:30\",\"origin\":null,\"key\":{\"i\":40},\"tuple\":{\"i\":40,\"j\":10}}"}

IMHO can we name it local_conflict_tuples? Because remote tuples may
conflict with multiple local tuples, I think local_conflict_tuple
might be more relevant. But OTOH we are storing other information as
well, not just tuples so maybe
local_tuples_detail/local_tuples_info/local_tuples_data make more
sense. So maybe I am fine with 'local_tuples_detail' lets see if
there are any other thoughts?

> ~~
>
> patch002 works well in my testing done so far.
>
> thanks
> Shveta

--
Regards,
Dilip Kumar
Google