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 1wTtPd-000ocW-2W for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jun 2026 03:34:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTtPb-008eFL-0q for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jun 2026 03:33:59 +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 1wTtPa-008eFC-2s for pgsql-hackers@lists.postgresql.org; Mon, 01 Jun 2026 03:33:59 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTtPY-00000000aLH-2Try for pgsql-hackers@lists.postgresql.org; Mon, 01 Jun 2026 03:33:58 +0000 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5aa68d9d4a3so766484e87.2 for ; Sun, 31 May 2026 20:33:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780284835; cv=none; d=google.com; s=arc-20240605; b=ajD2vAsDzHCs5epXtQTVblAlqfCSkv6QYtsKcA7oj66rqkJyG8mhHJFDwlJlLWp+EF aC+4VYtWFFM8FYQA+OTOSAulYPXfay/j/CfGxh/BYEmaAIqCaErZ+sBnihVAdcAoHtcH AXUuXE64MUJVsayoaY5mfVyVlIBaOaLR8bRQuNO95VFoCcLfYV3q5uWfxUKdv2B3s5m/ /8IVoNzmmhzNgTg76Z+3FKji0CsnELli/k2dI48Kl8L1GHvFuaW/9ahvM/V7alhgMZ2b 3AKwxKz4aXC4ejzWI4TnT7VXAN/7gRS2TGyzvVzjh4fUq2vOsJfs5MrdzZHP9YI2UKTN FsqQ== 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=1md1Q5k29SIJJc43mlfDBItTT5COhYTcV8aDC685PDs=; fh=oWmRmKe1z/oAMEHfEv87xVWKmGY3bh1Wak1FH8Qr7nQ=; b=CRFvgAfRn9D0onfS+wPBm2N16DD15vYaF6hvCabB5IoYW4EqFW4C9bzsIC5s/O2eXE LjoOguoW5MiMmw/aPgaNb1HnOxJbTl8QXRRlcLWbLAiOfGUMCcPe8GUmUjTRGy8mKYWL qx1BeSdSChOUUuHH56+++TiQEOJaOCayblcDubHDZfiWjoa3upPFgbCLlgRKz2EnrNMm gZkWGAP1bqaPii95rD//Ymeiwq0Iya3EDOqUOMq8SBtFKTzj1gsednOkbWnBk42IFBTZ 05aUsbZf1MVQRltEN2P4tlnKeYtP0WBWZNOR3PpFydfsLzWMxIbvBaIy29kb1JaEEVTH srrg==; 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=1780284835; x=1780889635; 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=1md1Q5k29SIJJc43mlfDBItTT5COhYTcV8aDC685PDs=; b=dUuFyziZBEgrDjjMNH0wO+wKnE6S1/wf07cxu8eqlXezzElr2WebgF5mF+HiwHNQyF JyrAKqvicqrXuD+eN0aLZw/v5vcbg4UforLsdsq9d4R4Q5TisNMWPBIx2e7GexwfpaHx f4hZNo26iBbB/71rwmk/8Md9SrvdnQkmC2D1+8AlWbbSIvzQEyINykJzLkU8357Qpdsx eN4z+JIFEChgtJ0WARfJ/02OucoZhZaWhH066J8BhI1uUD44N9eTr9LRIJGFdJgYdPRT dIab5UQshcdUYTlt+d8GBfoX/QEhUmuX4ZuGQ878cOQ0IjNqgz5cJStsAATM4NnBLXEn sc0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780284835; x=1780889635; 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=1md1Q5k29SIJJc43mlfDBItTT5COhYTcV8aDC685PDs=; b=lZ3UCgR0nA23DZOu/RvXulCyrz7qgR1Mt1MHO12laDzDzEpJh9rE43napB4+wwYLQb D1Tu7LrdriORy5m0ZQCufUcir1Z4J284eB5WEq1sjJ7L05arG/dY6gXgfv6bK/l6sJzk 6xp7+BSaL+ECyTJc+uTZPYeQFkRZhrPU57Fno9xCWXW1GHuw9DCHOGTt74OcAlJVRsJd 6nsVi8oC/mPQnaVbrANlQq8AnXmDDTnJsWnBOI0bxIMfz5Mr7OCSyyzXQfTDP1PDGerW Jzyh11h+VmEknECCnu+HeG8dnl6FEiJPgT9nMyP2HCpkiJ6f+fIxTKSuRKaSNVY3YO5Q ekjA== X-Forwarded-Encrypted: i=1; AFNElJ8fQbonPa1/F2fByvqjbmedtjusNzMoWhSv3HdWX5oGqQ9+hea1RhvNidACBl28wxwOjeQ7qBfdoYRBRoue@lists.postgresql.org X-Gm-Message-State: AOJu0YzgW+mwgEV8XRxWjU7+u2qUSgmAHDNuMIQtSPOIpGGJWeBm1u1j lTQRpmCnjVB9O5DvAr+56U2DgRTX5csIpNXnO27XLF3PSmQegB5YgIflQdYcXTWq9NSAIqQSchQ UNmQZ78ocnYye8pb06jcecfvXVLSsXKA= X-Gm-Gg: Acq92OHaTfvycqnVpQkpLEpTn8Y9/4gfcTDK0V/uDJBXdH8Wxm5Z1hKtOki7IYWcPqB cz25TFZuQyMQgbSzBr9lOm1F9ID8M6oMUDPSka+/L8rP8iA2F/3gNJprA87l1Lk+fqbsZdWGb9Q uN4YtATbkE7kwvzAljmqm/31Ehht1y2Oj/pjo+fXzqMwtupxKBT35ZOUQSAgKjegRXda0qC0a1D E0FL/IvCnVLYPMG6+aOhOtav8LKarDKsOgf6VwxrhDdplXf0di1mrACbVs7/lSuz6Wc0mFHrK6m L7l2X+P/3+BDOlrrenFwZK3iKx71DsDYdOwLteo2tzkuAjCQ X-Received: by 2002:a05:6512:15a4:b0:5aa:7039:706e with SMTP id 2adb3069b0e04-5aa7039711cmr27824e87.29.1780284834423; Sun, 31 May 2026 20:33:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Mon, 1 Jun 2026 09:03:36 +0530 X-Gm-Features: AVHnY4KGIboH0xCwo966AfoggU2RMQCApbO1yFa_5UlKa0bVmLHgOxBp0e79cS8 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Peter Smith Cc: Amit Kapila , Nisha Moond , vignesh C , shveta malik , 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, Jun 1, 2026 at 7:10=E2=80=AFAM Peter Smith = wrote: > > On Sun, May 31, 2026 at 9:54=E2=80=AFPM Amit Kapila wrote: > > > > On Sat, May 30, 2026 at 1:12=E2=80=AFAM Dilip Kumar wrote: > > > > > > > Few comments on 0001 and 0002 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > 1. > > + Oid subconflictlogrelid; /* Relid of the conflict log table. = */ > > #ifdef CATALOG_VARLEN /* variable-length fields start here */ > > + /* > > + * Strategy for logging replication conflicts: > > + * 'log' - server log only, > > + * 'table' - conflict log table only, > > + * 'all' - both log and table. > > + */ > > + text subconflictlogdest BKI_FORCE_NOT_NULL; > > > > 'log' sounds redundant in the above two field names. I feel naming > > them as subconflictrelid and subconflictdest should be sufficient. > > I think removing the word 'log' would introduce ambiguity. > > IMO > A "conflict" is a *thing* (e.g. constraint violation) that happened. > And the "conflict log" is the *log* of the thing that happened. > > e.g. "subconflictlogrelid" is clearly the relid of the conflict log > (CLT), but if it was just called "subconflictrelid" that sounds more > like the relid of where the conflict occurred. I agree with Peter that `subconflictlogrelid` makes more sense to indicate this is the conflict log table's relid, not the conflicting table's relid. I do not have any strong opinion about subconflictlogdest, IMHO subconflictlogdest, subconflictdest both sounds fine. > > 2. If you agree with the above, then let's make similar changes at > > other places in the patch. We can change > > alter_sub_conflictlogdestination to alter_sub_conflict_destination. > > Also, similar to AlterSubscription_refresh and > > AlterSubscription_refresh_seq, we can name this new function as > > AlterSubscription_conflict_dest. > > > > 3. Now, let's consider whether we should change the option name to > > conflict_data_destination instead of conflict_log_destination? The > > reason I am asking to consider this change is that one of the option > > values is 'log', so it sounded a bit odd to name the option as > > conflict_log_destination. If we change this then we can consider > > changing the name of Enum ConflictLogDest as well. IMHO the 'log' in name conflict_log_destination doesn't really sounds confusing with destination 'log'. The conflict_log_destination clearly indicates the destination for the conflict log whereas the log in values "log/table/all" says the destination is server logs. --=20 Regards, Dilip Kumar Google