Re: Proposal: Conflict log history table for Logical Replication

On Wed, Aug 26, 2026 at 5:54 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> > Using NULL for local_conflicts in the latter two cases would make the
> > column's semantics clearer and the output easier for users to query.

Regarding the fix done for above:

insert_conflict_log_tuple:
+ * In update_missing and delete_missing conflicts, there are no local
+ * conflicting rows, so set local_conflicts to NULL.
*/
+ if (conflict_type != CT_UPDATE_MISSING &&
+ conflict_type != CT_DELETE_MISSING)
+ values[attno++] = build_local_conflicts_json_array(conflicttuples);
+ else
+ nulls[attno++] = true;

I think a better way to handle this would be to have conflicttuples
reach here as NULL for these two conflict types, rather than
hard-coding the behavior here. If we pass conflicttuples as NULL to
ReportApplyConflict() for the these 2 conflicts from
apply_handle_update_internal() and apply_handle_delete_internal(), we
should be good IMO. ReportApplyConflict() and
errdetail_apply_conflict() don't actually use conflicttuples for these
two conflict types, so passing it as NULL should work. But I might
overlook something, so please give it a try once.

thanks
Shveta