Re: Proposal: Conflict log history table for Logical Replication

On Wed, May 27, 2026 at 4:08 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> 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.

IIUC logical these all memory will be allocated under
ApplyMessageContext which is temporary and getting reset on every
logical message, so I think that contex is really for the purpose of
temporary allocation during each message processing and get reset
after the message is processed.

> 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?

Same is true for this as well.

--
Regards,
Dilip Kumar
Google