Re: Proposal: Conflict log history table for Logical Replication

I have not yet looked at v41. Here are the comments for v40

0003 and 0004: No comments.

0004 and 0005:

1)
In build_local_conflicts_json_array(), we have these:

+ json_datum = heap_copy_tuple_as_datum(tuple, tupdesc);
+
+ /*
+ * Build the higher level JSON datum in format described in function
+ * header.
+ */
+ json_datum = DirectFunctionCall1(row_to_json, json_datum);

We have first allocation to 'json_datum' via
heap_copy_tuple_as_datum() and then second via row_to_json() call. So
we are overwriting first allocation. Which memory context are we using
here for this allocation? IIUC, if the conflict is non-error one, we
may accumulate these memory chunks in long running worker loop which
may gradually bloat the memory. Let me know if my undertstanding is
wrong.

Same situation in tuple_table_slot_to_indextup_json and
tuple_table_slot_to_json_datum as well.

2)
Same in ReportApplyConflict(), if elevel is not ERROR, should we worry
about freeing 'err_detail' after error-reporting or does some
short-lived context handle it?

thanks
Shveta