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 1wgfeQ-006KEv-1e for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 09:30:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wgfeP-00GUwf-1W for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 09:30:05 +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 1wgfeP-00GUwT-0Q for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 09:30:05 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wgfeN-000000021jm-0G3E for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 09:30:04 +0000 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-381ed661712so2366177a91.2 for ; Mon, 06 Jul 2026 02:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783330200; cv=none; d=google.com; s=arc-20260327; b=WtG4KKftCS6v9OzzM4rRYwjv/zmfpqM6KcqaL/q1zYhSHFX2pYo/GcK5zq8oCiVMpu bAyyPNZOTv4HYceIyFLx++UmlpfwViijRT+czsSmenuXrNUv8h18PlRRUG31qexZoQ8f pyxc9yJrMok19kB26q43NqnfngPmqPQRvPPPHd/A/xb3iFhxzfBT2jVijw+x6xDSFhN0 pw/xKVbwqmfHF799Mw9N4xptjSL5G+AKUjPXVGd6QiQI9K/7qDnPgYND3QKHCgav64eT RrDDi21nh54rjRfqzSW4nP2YY71kD85zWC8G6Nr7P96tnkhs1zjq6oLNFVdjQPqTVdbr kvcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8VLB27NQlJFCgK8xaOngJQ3uALhDY1NWcyFcGbWuHj8=; fh=ZX3bL8bK/s6pqrbHHu5HN9LIZeG4CqVd+69ttEjlYtA=; b=WzVTA9FnTPbqVSQeUCOvFNwVU8VDCh2wlQUWwSMypXJnPvxln0zVcrckeVu8qlN07a 8b/NUQltCgONeNl2uZO2uFUKkx5jlf55rqSYsVlXWY3hCIrdeEIrenxmVDZmBYflCFZA pr67pCZgn9rewgS0DR3h+k3+0a2Opz7Z0k8xyQzCrcGFgojdTuNNQyp3kmq+JGT5h972 SvrfYip8KkUi5w2ssFaHJYm1UHM8X8rM+0+kNtGrOslDIJPXs6on7csrYab6m3lDxHj3 FvK8e2NcrCt28xqVwp5uY5n3V/XfiHy4bS0+RqIyhoNbYgbDjmnBEp+nBLpxXtt2j/4X GAkw==; 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=1783330200; x=1783935000; 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=8VLB27NQlJFCgK8xaOngJQ3uALhDY1NWcyFcGbWuHj8=; b=m96WTsejV3KXVE6vKq1RPlFrHten4eNhc7cDiKiyUV3drNILxv0Xh6vi8b0PRmb6Vl 8tVujS5Gtzd6g4EkysHzGjJ+5ep0YNfOWy1cJs6xuQnfLRnuuOXZXyZDQYOOhYtYX5eI 1PDymZdOMfZBTN/ipqZPWCNLTtdaKJAlmVya/c2Y0ryqFis0y4HNa5XgdbwmtcQEtzFt WWQ693F963VFPOxQEbzCdTOUVFlt7XmFy7Ce7cmndX6Ey2Cp2K3l26lrACPSdDvlGrXV nd6OhN1hADBLcR238eHMT7PzRYB0oHImZclXcSih3E7BYfdRXOtuHr3ZNPdNFEvJh5aw 3r+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783330200; x=1783935000; 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=8VLB27NQlJFCgK8xaOngJQ3uALhDY1NWcyFcGbWuHj8=; b=Ho78kjPfJNyA0vnI+U/rn2bViahKhCtyQcqRwvqtgL/5057qCcBlKOBEM3gu31ortB COSrciYpuJCq/xZ4aYm53lxirueVgCAtUra06J/TJ5mdms6cvOzTkN/1TqnLtqiMrjt6 JoeRzYncBaquATxM3tugHexaA4Yjy3155695bbcEfV33O2K4Zl1FGdFB5T2PH8dJn2iI mu9VdB7uQBd2zLQgygd9UUtnzf8IkwCZ+17Jo1iXLhfPYjbLuIeDw17vVsGWr6bcEsPa XpT99OYlUp/rrhOdU8qsqNrAPXIqkaQ6j1Ny9FN8Nd3sY6NYK2f8zDnrPLhZMw+WjqQR 6bTA== X-Forwarded-Encrypted: i=1; AHgh+RqGRFj6yE8VGgI3dUZHSj4gFRryiTGo3ujl57IC9lbXG4emraUpOQZ0g0F6aierorV1GVqICJP37RQxFL9g@lists.postgresql.org X-Gm-Message-State: AOJu0YyERfDh82W/SnHnLkg3O8f5GieK6B8op30Nyuqizegs74repFBj lgBsT51ZRl7cOZIn9hWQ6onzEtWt7TEdEeFDADJ9PWrsIEdOl9bZx/xWIjV3y7ZH+lerR2PRWZa ZLGLWy01whPbXpt7d8fYqeQ5cJ572DKg= X-Gm-Gg: AfdE7cmwpdt4emi2vC2S27mCMoKqUha7XgWpO5qXnXPP7q7VZS7r8MvfDRrRBYu+/4t h7pvpWlOFYsPyjW9k2Wwh8Cw+9W6wCbTISBoFAsAeZK1r6zejGLsjd63aijTZ6ZthdsCWfEdnig x+Po8IuNyVP1KD8yXIOy/h3bPKlaPmq/AM2/C6+xxp91sd/E3vg0pB2AOL7u+E/tIC8SvqgBlqO gL9bNwNonYr2VCKo5Snw9LEG2Hi7Mk7V0oKWC+cz4Vo9XJveAno3lK9GlL8Cpw3u2/b/jmX0T3a i6ze1t2NNlAxodk7crlUtSRt1VwAzVwfLkf91aFpRnRLlbrlkaqRPm35Wuwrs2GPFN+OFvjMvxw = X-Received: by 2002:a17:90b:5544:b0:37e:1c8f:3dff with SMTP id 98e67ed59e1d1-382808b3fd5mr9379768a91.11.1783330198983; Mon, 06 Jul 2026 02:29:58 -0700 (PDT) MIME-Version: 1.0 References: From: shveta malik Date: Mon, 6 Jul 2026 14:59:46 +0530 X-Gm-Features: AVVi8Cd-BZK2u_f_Bc5imyYpWDx9wdqmTY7DSQ3EyO6vabjFBOCz-6-zGhA6VI0 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Amit Kapila , Peter Smith , vignesh C , Nisha Moond , 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 Mon, Jul 6, 2026 at 12:52=E2=80=AFPM Dilip Kumar = wrote: > > > Attached patch fixes comments raised by Nisha, Shaveta and separates > out the logical-replication.sgml changes to a new patch. > Thanks. Please find a few comments for the review done so far (0001 alone): 1) docs of v64-001 does not compile alone unless we install 002 as well. Perhaps thes sections are probelematic: + Conflict details are recorded in the server log. This is + the default behavior. See + + for details. + querying and analysis of conflicts. See + + for details. These try to point to 002's new sections. We can move these lines as well to 002. 2) + if (pending_conflict_log.tuple !=3D NULL) + { + heap_freetuple(pending_conflict_log.tuple); + pending_conflict_log.tuple =3D NULL; + } + if (pending_conflict_log.errcontext_str !=3D NULL) We can leave a blank line between 2 if-blocks to make these more readbale, else they give a feeling of if-else block. 3) ProcessPendingConflictLogTuple, InsertConflictLogTuple and ReportApplyConflict: all uses cleanup similar to below: if (pending_conflict_log.tuple !=3D NULL) { heap_freetuple(pending_conflict_log.tuple); pending_conflict_log.tuple =3D NULL; } if (pending_conflict_log.errcontext_str !=3D NULL) { pfree(pending_conflict_log.errcontext_str); pending_conflict_log.errcontext_str =3D NULL; } A small helper (say ResetPendingConflictLog()) would remove duplication and make future maintenance easier. 4) In build_local_conflicts_json_array(), we are first building a list of JSON datums and then copying them into an array. This is okay, but since num_conflicts can be computed upfront, do you think we could directly allocate the array, avoiding the temproary list. Instead of below steps: + foreach_ptr(ConflictTupleInfo, conflicttuple, conflicttuples) + { .... + json_datum =3D DirectFunctionCall1(row_to_json, datum); ... + /* Add to the array element. */ + json_datums =3D lappend(json_datums, (void *) json_datum); + } + num_conflicts =3D list_length(json_datums); + + json_datum_array =3D palloc_array(Datum, num_conflicts); + + i =3D 0; + foreach(lc, json_datums) + { + json_datum_array[i] =3D (Datum) lfirst(lc); + i++; + } can we do: num_conflicts =3D list_length(conflicttuples); json_datum_array =3D palloc_array(Datum, num_conflicts); foreach_ptr(ConflictTupleInfo, conflicttuple, conflicttuples) { .... json_datum_array[i++] =3D DirectFunctionCall1(row_to_json, datum); } thanks Shveta