Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wTa7i-000caR-1Z for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 06:58:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTa7g-0075k8-2F for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 06:58:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wTa7g-0075jy-18 for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 06:58:12 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTa7e-00000000Qls-0eUF for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 06:58:11 +0000 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5aa68d9d56fso270474e87.2 for ; Sat, 30 May 2026 23:58:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780210689; cv=none; d=google.com; s=arc-20240605; b=I4zTrf7yUjSdLR1G06ogSlyjRfx74PwfLp9h/j2yAMxlmK0oDKZmb01+Lqf21TWcY9 iPnUpmHgUuJj3g7+NEAQe21KBPD4S1wWBQc6c8amiJzer5+iOlDOdoXfBnunaJw05yyz HN2zeHWjTHxPruiOUmF2RhVpl+MntoOjMCW2gTbHsMBITpxTGVQRh15NQIP+KP73JLHl Mc04TULiuy8scu2aAqGivj8A+skiD21eoF5Ms7qjtZpCTvK9/0ZarAdTAJwqzSsVG+9y U7y51aMSUzbDC7tFTpD3g2UPh6B5vTkc3ZNV37hKuEyN7XXkUUK4MksAT9y+1hGbCx1x 8LOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hyWRAjz17Ug3iiBITHo+xjw1OWcmiry+o8ULhKuuIxk=; fh=DtBvq5+kwcrog7xl5uNIs/6BwRFDCGpHPXAJjAuSpYk=; b=AoXQd1ePSHtjb0p46rr9wwOkLXm9EswAV8icgKUw6ohY0fcWPLkP9S6ZCULkUZ1t9N U75hI8mwfN1Rk0FO8gNRvGc3ooo1SaamMDUA6AiY5ko3yZSmbpA35JL18xaAF3pkBrZM MKCGE1MMZQd1e+7rleKF5hYFd0E7itzGQwY/nf7Sj4sWLZ9qbvhR7Fto8RMVRwjjNHZn FIFTgyUMg2X+h+gLupnVNgk/DxyhljckcrYG6YEwv1YJn9y8qSRUvQe7mCk//3tlmJrQ i1nxluN/F5+Tz7LiFgvUOU/V9YJwVsd+Zz7IC36+7JsQFrWMM5bJV7sroTPAsrhVeIen 7+pA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780210689; x=1780815489; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hyWRAjz17Ug3iiBITHo+xjw1OWcmiry+o8ULhKuuIxk=; b=TfNnbIQaHAbI6HSYGoz8LZyNnGdSTXAZ0YVXt6ST913TPJrtoPCgEdqAXxz4ltw2/I F8UowDrvxrBfQUF31ywn9YgLsW8k7irOgUDjDoNbTeWm1nXeEceFoqeAi16MEx7DVqP7 KmnfEZAFUvfv14OaOtUso6MNEnw9vPgDB+mKjibA4X1XtAu6o5UqjwV7FOt7VF1uH8sG NpOeJ/VsNdT8kHyA2NEWTnF7fwWdJppisBhQAMyRTFW1WgtpyiM2dem2At0GLeR6dmuF R541cnAorPF+PCwDwOCForybHlheqRFWdM7OM/fUo9Cpx8fZ8vv2XKLKi/RtCRNTQYtG 4LhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780210689; x=1780815489; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hyWRAjz17Ug3iiBITHo+xjw1OWcmiry+o8ULhKuuIxk=; b=VaXhmQHPw+FccgTYzelAwjG26AMy0Eak2gXNB2GnmDPJ3uHxg1oy9uC8JaBKO7krGZ LZNEJquWhRnWWP3HxWsr9JJCJZuMAObmrfpqJbv4vN5WYFilhJjnHeXR59iVT3Z6vqHA t5SxJbdXFxENxzqlGGxtN8cwEB2RsH4+IN801Bl0kn66SQqEr8ZXO2jmyOQlQh6olcpt RptpOINbkoQJBFtHoFRodjPpfv7ggCY6msvQGCJtadr0PUaNE94QtVdrNpE/wVczD8r9 enfPx8gyMBmQREgnpkkKSPkpV6NiUD66KrOYqoVcKtViPQNNXwBTHWsNOD9dMCUnSOh2 v0dA== X-Forwarded-Encrypted: i=1; AFNElJ+oUSetC+w7IP9hnGS+cWl9S965JcJNbB+lUDQ6npq10eSsXhT5J+mx6AtlpCJdUJaBiRBJRnTCxRQFegYP@lists.postgresql.org X-Gm-Message-State: AOJu0Yy20A/Scwc5G8iJZVPstFZWHhB3v4+I8Xgu6YyZox3q4tw1kQUe kmROb+tnxQhLw3Lw8EG0goeROr7q5/B0q7afKF1eApnIJxRcBugpjeBPxZ+IAhS0Bb2TmV7S4iq dBQVZ7AJoXgAc4/DjLldYrAMLT1Cmv2Q= X-Gm-Gg: Acq92OHlmijKhYeKE0AYARZT2UpGkJIyMeyKFM/NKoUvgKrcIyaUIIzQgF5kFNsIp3O bYoXfJNFkvVZF0ZuRypsFugDpcLtbDy1q3hUzZQzsIFNI8AX+4X2vyzK5wgy5y/mWJ0nRnNbBJl b43EPphEWMDe0jxc2IX3Ls1PFmLs00Y3D/gOFiGVnAAAKhEGEXMSAeEWuMWN+tPb/pjH5dDYaGY zW84DAWwaNKXQnXpEv7zptWiWXnxUdS+1IJMWN92t+npKyjAIDqaqmhZ6qur8j9LdmaCRr2TGd1 6V8M0hiVDK1SjP4Cl2o= X-Received: by 2002:a05:6512:3989:b0:5aa:6b85:85cf with SMTP id 2adb3069b0e04-5aa6b8589b2mr70774e87.10.1780210688490; Sat, 30 May 2026 23:58:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Sun, 31 May 2026 12:27:48 +0530 X-Gm-Features: AVHnY4Jud1jJwQ3onCpYaycPhfGVtPKFsjZ1ico5DLd1TeAHpSTNIabWX0Qye7g Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: vignesh C , Nisha Moond , Peter Smith , Amit Kapila , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, May 27, 2026 at 4:08=E2=80=AFPM shveta malik 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 =3D heap_copy_tuple_as_datum(tuple, tupdesc); > + > + /* > + * Build the higher level JSON datum in format described in function > + * header. > + */ > + json_datum =3D 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. --=20 Regards, Dilip Kumar Google