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 1wgoFH-006Puz-0s for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 18:40:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wgoFF-002QQr-2q for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 18:40:41 +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 1wgoFF-002QQg-1h for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 18:40:41 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wgoFB-000000026kW-17tk for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 18:40:39 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-c126fe7d0f3so433696866b.0 for ; Mon, 06 Jul 2026 11:40:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783363236; cv=none; d=google.com; s=arc-20260327; b=dZTSgyWwNsqMwVHM/+Cc1xQBuowXBPznuRg6yZGCAVlW5t77I/p4dYDXCXhq/muSwg mk9hFbBf7y7rcsgN/YsbbuKVEsVvubaCCkTaoqUpwy1RAgplu7UXoxYtSuS9Fuv0f6JC c/SVLPkuhuPWBiZt/xAX9yd7ihjObVWQP2g5DCS09khv2lOsNjJcaqoY21mpqwd6SRV1 /gyIGRqzpIPUgQN7dEQS6V7V9pxxv9CPP4P1nxAMIOsEwOK+b57/YwfgKsSde8a7vXNC dp8anuvhZANMYtBXmRgUjIW04Immg8kXsX6wkyRUWvNC19jDyj+NzFU9VYzfttDS4D/6 0hmA== 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=FaUV/mf2+WDTG6vGkYKgizeWisWF+uuHQyxb+J6UNWs=; fh=qoH5TlGBLX9eWAoSpncPsThKVLEkXuC7EHKIDq0hOKc=; b=Vrgx+nB3sfBO9I3uXfjY0CZx/wrie0Whw5X5BE0QU7ByV0vYACS/6aQ1Zo5GuKw3Gj EhLotpx/1kULq2KCBYc+u8hChpNFjXVg6Kfoyw5ivWZjvTUJo4zGImEzUX19KKnk4/Wi UphhsJbWgTZ+Ur3hwjAdT+8DRJ3HUb7c9DZSNhU5fRVS4UwYcJ8CGQ3apok+AP8AyUfZ DFZ5GcF63XdZA/0Xivb8uzdieUXIo3TnnuFp0CAJJR912cIbtq8FgLMuxj+RpTzKQWY6 3P+6b4csCjyEMqQtANXLo3+IN0I4yn3BJULK5V1wzvR2lOpAm2HziY8DxUTZQxlDC6KM 9w5w==; 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=1783363236; x=1783968036; 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=FaUV/mf2+WDTG6vGkYKgizeWisWF+uuHQyxb+J6UNWs=; b=ZK4/XE9oVvwbq74lOp4jBuBoGn0fqYm1lxGKOx4CIol5qO2ADcJxGsVa8zY6DqVvnK etv6rXrUtlcSU6PtWpI7caWEjSBZ3Uzt6t25ZVF35D6ot2hd3rRANReEUomd6DlCVfWc lHxsC4yr17PJmiKm0VMsuvPOa2nqJkYwJ8UbwGZ2MLOkiWpmPGu0JtyPVpVl3h7232DK sdYdv9bVqkRP5TmArmppUC3aa81Lesq82kc9C0nTrN0cAjyHoZkl3T6o3bgiP/l9YJDs YeRGH/jfJWK7Una00q7rhFBRifq6Xka08viHttuSDHZGn8R4EZk3iY2CvgWjtZw4o4Nn Tnrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783363236; x=1783968036; 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=FaUV/mf2+WDTG6vGkYKgizeWisWF+uuHQyxb+J6UNWs=; b=bpptzhnRXMxAXHr348v7DRU7p1Xz+Gu5A+e+73vYko3S+15Y/DG2vRcJq0GyeqZSSP VDepWl0K/+iCgijtyUFed2z4tZ2rIws/dqrtECHo1SVjjaR/7XtNkxLLi06YpxPSkWrA KYM738wpbAT7kjwGrekXbXVq64OsiChevQGdl+AcGmT8ezpq9+peIyX77YAXS65qSKZ5 bTPQ7FqsINmkMZ6h3bOjpNbA8BhnUCTXoceAVBk/4ozBHt9JgPs5vnJQJ7ABW5MXsjrw 4HCFtbjIUFS6zadVd6zhcifKUdDNiiFCFxlT37yEWAcob10z9fSY1pNkzK5lN4Y84Lcp DioQ== X-Forwarded-Encrypted: i=1; AHgh+Rp4fe5rHfq4AVo5parm/xr3623DShnk5oIBix94wBIQd2IkOsEqIolByoA9ZUAO1YNSYhGj0dHbfe1bzHtD@lists.postgresql.org X-Gm-Message-State: AOJu0YwzVT5IGI/RA06XmuW6sWUIhsqrHUOwwOx4ddX9jN2Nd3qVLUcm A2jyiNTGoEejBmmi1mQ+uLd7XhoHZqYvxFcEtwHaw68t5GcmAjSMeNOj58CPA7xOjQw89Z0qm54 bcACXQs0Sc2rrSwkJTPsAhPbrIP20DHs= X-Gm-Gg: AfdE7cmZ/uY67cu9rdy6Cnw2WtkrS4d8ObrpLdn2JCoCVCkMV2Wwzhtru9IBPZWtE3c Ms/1vdU4GV9sVAI5qLWQQv2xrktDjB1EFP/fWdllZiWz10v1Y89I0vpbO6ELZ9ECGkDnISnk+TR SsfaCyJXakAW0axwXCMgm/mK0LT5G8YUesRtZxDkIB+bYWd2yjYYPjiRNp8zZgehR4I3wH8IR07 TeyCSwXGmGQ4Jp0N/JVQLkqoqpcA8WlRZTCXr6QDfycKp8Nh82pJOWVYnLq2lzbOKLYBaSoeNup P6wWBewzNNzwRpKBovKDkAEFogbl X-Received: by 2002:a17:907:9811:b0:c07:e025:1549 with SMTP id a640c23a62f3a-c15a67f75cbmr104389666b.15.1783363236195; Mon, 06 Jul 2026 11:40:36 -0700 (PDT) MIME-Version: 1.0 References: From: Robert Haas Date: Mon, 6 Jul 2026 14:40:23 -0400 X-Gm-Features: AVVi8Cc408y4MS5DAy6hj-B6H0FOq4xHw6dlOF4mTTT9uUaIznxy6W1RRJb-skg Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: shveta malik , Amit Kapila , Peter Smith , vignesh C , Nisha Moond , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers 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 Thu, Jul 2, 2026 at 4:09=E2=80=AFAM Dilip Kumar = wrote: > I rebased the remaining patches on top of HEAD. So far, I have run > pgindent and completed the doc merge for 0001. The 0002 and 0003 are > just rebased. I just saw that a preparatory commit for this feature went in and it triggered me to look at this thread. What v63-0001 does is: when an error is thrown, the try/catch block sets aside the error, calls AbortOutOfAnyTransaction(), tries to insert the conflict tuple, and then re-throws the error. I think this is an entirely unacceptable design, for two reasons: 1. Setting aside the error in the middle of a try/catch block like this seems completely unsafe. What if there's another try/catch block on the stack that needs to run before AbortOutOfAnyTransaction fires()? 2. If inserting into the conflict table itself errors out, then the conflict log table will be permanently out-of-sync with the status of the replicated table. Andres put a tremendous amount of work into ensuring that logical decoding could always safely resume from the last-confirmed point, and I don't see why logging of conflicts should be held to a lesser standard. If this goes in like this, we'll have a never-ending series of bug reports due to low-probability failures to insert into the conflict table, and we'll never be able to fix all of those, because this is broken by design. IMHO, this preparatory commit should be reverted and this entire patch set needs to be sent back to the drawing board for a total redesign. I'm open to the idea that I've misunderstood the situation but from where I'm sitting it seems pretty shocking that any part of this would have gotten committed with things as they are. --=20 Robert Haas EDB: http://www.enterprisedb.com