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 1wTrdp-000ng7-2v for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jun 2026 01:40:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTrdo-008M31-0D for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Jun 2026 01:40:32 +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 1wTrdn-008M2t-2O for pgsql-hackers@lists.postgresql.org; Mon, 01 Jun 2026 01:40:32 +0000 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTrdl-00000000ZRd-21sY for pgsql-hackers@lists.postgresql.org; Mon, 01 Jun 2026 01:40:31 +0000 Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-51720674eb7so40492751cf.1 for ; Sun, 31 May 2026 18:40:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780278026; cv=none; d=google.com; s=arc-20240605; b=WURfqH3/Bq2mhw8wWwkyYrN31nVm4wf68d9jXTMfLh/W5o0cINCuhpEDkrt4v4F1Oh 4QuuN6q7vMq8SWwiHmfcOJM3pEqJoaApdGWgAAKZ5SSsu0vCwDoZrdUhIXFJGCOIoVLM 2qcZBjDBsnkdbik2HNXntwQCEerlwewvOnah6W1SeX7S7kn/AxectZyor3ezZBKc7o91 43iSPjw2Wa7q4TQwMu5D6gJp+h8iQLa2DXL651e/PBtBsp2XfJ9wx9dKs9zFplhWy22d wK1goWLqKjJ+b+0CUwvtdJZRMyctzcAh463oSmqVI6fO/PK12rEKHIQNixFeoBilu2kt dDTw== 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=sSSC6/JmCgJSiIgYQiZVaRb6Kq7xdJwuZ74HmtguUNg=; fh=Z+ZZVIoIW6awX5XYmYCG9VJVYP8Lu6RspjIUsEfIoRc=; b=WgUnZtMQQPVejGXRmwveg+T+LSJ6Mch21ryryUTfL1+x2IjZjTY/htqiyvXpjbAs1t l+0GZgPq8DV5Y7sb9gTo2dxpJg/vtpWPJvJLtDL/arHW/8TNu//aEVGrFWQRL9bae6ya ewxVICrAXt+xQuOdpo/mEQkZEZuVoM69083bledMBpgmv5L72a9eGaZumlGNq9Edw84S 6ez/Xq0SpLy5kfTx11oCQx6TYU1IKBzJmPp0ZZCKsZf+HOK/x8ysiE9UfPiq2banUVhd +cZbLq4EM9ddjh3gQLV7/p+ULNMivp3vjfVNfEr4YPWt7NieD4bdq5EIqBgRv/rHHKjg DLbA==; 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=1780278026; x=1780882826; 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=sSSC6/JmCgJSiIgYQiZVaRb6Kq7xdJwuZ74HmtguUNg=; b=TaiggANqmyiQmU9gwOzGAiG7CkEWqVwOnYFVMZUS7fPnBHbP/RLXtEWxzMFRlHwKVB jkNMizOCN2tVBw7GmYVQwkadqD9jdV4sZIzkSdfQnEVFMdiHVfz2Dtqe0jQpZhbIWnBV dxUTFIqXyQvyEpvuAHQmPfPbYhGirWQi0KBzUfRWRfkNzJFCvdVlFXkjBaye6klg3U4C viauDwRH1c4pD89qL/Nk1V9T79b3Bkq3tgzo9OQ1b7pPV0P6bGS0icdxb2Sw1oPKDpui PJvmM4xaiGGqyf1oqJyXqbuv7o1zvafnHGnrG/3mca6LaenyZ0jm4+4fJXCkdm+J0gLK bmqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780278026; x=1780882826; 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=sSSC6/JmCgJSiIgYQiZVaRb6Kq7xdJwuZ74HmtguUNg=; b=CBco7oiolNUrxMxnRugM/w5eUy4slQjQwXegvbvyrdwsmhOsVvTgvTA+3zFvsj4Ah7 J1tNmyGaEodWit5L7HQ8t5kuP1B2tgOvrWRDdyyCjyG9MvLXuKh1ZDkf9LHGA47YWvhC lqhuWHTKnUQZr7E7TaDDPbqCQi+E1GedTfJloGJYfkOU0D5LmRzoUJ77swcFhEQ7Qxdr GKP/0hbwhHSWu66KhKAtmpVEke+9pds3kOvxQcMG9x8YwS+Lh+uiN7Jsr91zWErFHdgZ TI9CuZcM2pECRg4p37PBSZ1D/HE9W6I08kqn9OMKmETl2GCnfDkHvN3bTOWVIgGLYsh9 /rnQ== X-Forwarded-Encrypted: i=1; AFNElJ+vyrRG3h6vmQNcLvoE63rF0p7YfADjRoCu1EWyiJAUva5CLajR2CbfLqWbUJVfP+TACTrwsLdlSjs1oI6s@lists.postgresql.org X-Gm-Message-State: AOJu0YxWNUI9ICL7L3miTJtTjvKSG78oLekiBvVx6luDqD9K3Aktyqzw 4PVHG2khJRzi4XucbpU2wwa2evd02Q5rFVJncdv+/zOxFV/y1LyVYEwOzLuwLqLVptFjsAHWrE0 E2sqs00e0e07pcsEQfBLZSp6ZIRm/iFc= X-Gm-Gg: Acq92OF9cSxBrdYhT1yE8K2oqNhHTV+obw7GvbS97GQAta7Wi1WYBK3YpQ0mNfv1tg5 AqN/JH+ULD3MAdAi24tpY7OFU+K628UYlVmhsmgiborR6AIBzZIZ0enlhldFvwQjVZA8OjK4IRa aOeLLo+GRxi6im8P0RFzDY4dPJG7q7DBUwWceX9HdjCn1+UW30rFldvZhwBEOpNB28WGC3tAjjE Of7D+DFqceIZnHtdQH6WHxZWb8TN2vFe2wp5PIQH+HSLqo7FDNSV0v/pp9zH5C+38wkmfmg9gCZ 9gHQbdRnU2HHjBlhJQ== X-Received: by 2002:a05:622a:1e91:b0:516:ddc3:6248 with SMTP id d75a77b69052e-5173a7d9075mr143080461cf.29.1780278026088; Sun, 31 May 2026 18:40:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 1 Jun 2026 11:39:58 +1000 X-Gm-Features: AVHnY4KCic9N7wGZV_GJ6bvElI_1C73bHpuuGp6TQdc_KMc1Z8KQLsvyJ606G5o Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: Dilip Kumar , 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 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. > > 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. > Another alternative for option name could be "conflict_reporting" with values "log/table/all" But, renaming the option may cause a cascade of necessary name changes to everything else in docs and code. e.g. Because the current option is "conflict_log_destination" we have the CLT (Conflict Log Table) e.g. If the option is "conflict_data_destination" then shouldn't the CLT become the CDD (Conflict Data Table). e.g. If the option is "conflict_reporting" then shouldn't the CLT become the CRT (Conflict Report Table). etc. =3D=3D=3D=3D=3D=3D Kind Regards, Peter Smith. Fujitsu Australia