On Wed, May 27, 2026 at 4:08 PM shveta malik <[email protected]> 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
