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 1wh170-006cPL-2C for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 08:25: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 1wh16y-005RWV-0g for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 08:25:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wh16x-005RWM-1y for pgsql-hackers@lists.postgresql.org; Tue, 07 Jul 2026 08:24:59 +0000 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wh16v-0000000203q-3YCQ for pgsql-hackers@lists.postgresql.org; Tue, 07 Jul 2026 08:24:58 +0000 Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-c9e30214d8fso2802317a12.3 for ; Tue, 07 Jul 2026 01:24:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783412697; cv=none; d=google.com; s=arc-20260327; b=jON9uagyE8WDqiNw0EsqKOi9FmmggAX/7z5fHMRBiyEm3nTaaa1b4U8ITe2yi0yGFr 0/7kdjz1Rl/fzMfWjRe2e0eI2V8kwzQVqxYruWqm6ABGihRCQH4mZR6CgucHlPNanWsa j+cU0zD+WlHc0pH0W5I9jlWiiPlyWfIxoMnqt0XpoF26JutzsZFW9xpbRtzukjO6xBEL a8oiuUMkLyAF2rIh29XWTBqmBywsFgdyc4XxCK9xbYcArKJbRPyMvrL4ia/+1EYdxYSr FyYHPUwFGobqKXrjECHQPm4CSneCBvhueaZmO6vqtSzcbVUYIi98jWqptx9WYQ+FOjeN /nJw== 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=vXj0EPao5Y1yfsJh/bo2LyH31ilfV/ceKSMNNcelmb0=; fh=2SFcx/PzcIjXIjAy+3Pc4QrbTbHvvTS8if/RUrGesrQ=; b=o2T/ldS8i6KwAE8AuLyF2kmYUQlWQeIT/J3NwSW/7urEaTnXj8s2P/S+KgzNHE9khd aA5Ugg8/Zcb5sQsX5k7diPUCalDK+PU4cwGUbv0EQO6k846iDhSa4tnKKzwvP/5htL/N lytKXrhgcMYk08nCoPWOwdedXK7XZufWttDASfJ5uAE1o0f95NoqnexqpofzeNx8uKpE x7az7yJ9ZJ/MZqDWqJigEMCFVX/DqpWxKjVxgbTslbh8Gs56iqeKFD/uplTC4G/Rfbbf IRBoBsI/Vo/YlQefvNHs8WIj7YzEGBito3GVVoXU4sx+59ELhO98vRQous1VS66duLw2 1gzQ==; 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=1783412697; x=1784017497; darn=lists.postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=vXj0EPao5Y1yfsJh/bo2LyH31ilfV/ceKSMNNcelmb0=; b=YYMHNGy+ozBoKHca3brFQH6wyzDVlqJNKp2u4J/uQz1uN+1LjRIWQFfpfWR+usC1YR 5gHb5S1k2R0ZkXpNCIf4Wwq+PoHFTMy0gdktVhxJOO0Tjx0kEvnX4lY8r/Rz01WUL0vY D39Jb29u6EbmWQDwv6lQ8hIpeP99H3C5qz4UkqWksuTIj+CHQJ08k9XChholv0teCGh+ mLt4qqSf00jpuuzngaPI5mX3ufwCw3ImMegOIxnBLwaJRbyvqVSQmN+cgKwK6F1HIVDm lyI6AkWSVO+6Fpm5E7lzOCJ4Guhqzo/py85MRoOX4gvWHdWFMor791Fd1S3FZ1Xgs3pl 9ktA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783412697; x=1784017497; h=content-transfer-encoding:content-type: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 :content-type; bh=vXj0EPao5Y1yfsJh/bo2LyH31ilfV/ceKSMNNcelmb0=; b=CgTRJEHKRUf07Ip1B3kj5bzfb8E8s5y0i1bo8FlQB9XHqS49wh+nyjeQDwb/sslh/r PJNUaJ0xnFZ7bub4dMc9vE6+nz7CZNemTacMEtxODp04EM8N4AcdFNAlmjZ9QILaGluk S5eDNZGkXXGst/vVVX9tMN0WTNPyXhPNzVDfFq1GvMbr/9QofpS0ihy96V1qRXMh9732 47kSWouNGijQjmJA8mKCsutAdE5UrFHm5sBVvhXxwkdijNdDUdkMaD/1r4QQbvR0o5va KZl6D/bnOSAO9cIsygnkuwGWDaZXXjGbpIYYHUp0YvifAVuqRY3A8uFbMGtCQkY2R11Z BX3g== X-Forwarded-Encrypted: i=1; AHgh+RoScD2MSZ7BGRmVnuxM5IoTP8iurUoXKjKVYvYhY0lgo/F/NLoyVHyAi7d/UA4fiRrcPiv5tpudyN13WTSp@lists.postgresql.org X-Gm-Message-State: AOJu0Yw3ZyViAko+XgfL4lehIjFFOTidNwuE14MHQryanDLZddDJrVC0 R+ZLOWOOTk89VNidTMvSlj2grzQ5Gq8254S6cJrDhR9+CtmBl2zf8C7r7JjOYBVpq7nSQdAviUG SOWINWuDBCLb2EaxRBFAw+BU06hKrhBM= X-Gm-Gg: AfdE7ckUC1ntfGd3MRcuWJCE0oBDW0sm7Z/Bf1um0jXnspahhPakh9ppZp5OzFlKlQu z1LLh1PVuzOdPHSHpkqhC9ZzzdZkQEW1XijN4GDTvMGAbvL3pKumo8JElrB2crpIGcj2yMLHGjQ WDv8SvtwktMBHzk/jT70JLazhGgj+kKuWHv+bRxNmWj4o9AVNYwV5IAxHTPEVXnkWYea9S6U7XA kFWXau1u8sDcGXPrkaNF5p/m4DDW0pT9+/MQsIaM0+OK+7ZUg0wyx2EsxNWV3vWQ2eiUSurUGWv Q4HM4RnI+oh7pIB095l8mrGVgfLvi/rhhceg6zHHFF4rAjf/1x3K/Gr92ALmRZwgjJNlRmvLOSk = X-Received: by 2002:a05:6a21:3f91:b0:3bf:7f0b:2f6e with SMTP id adf61e73a8af0-3c08eecba48mr4460819637.46.1783412696653; Tue, 07 Jul 2026 01:24:56 -0700 (PDT) MIME-Version: 1.0 References: From: Amit Kapila Date: Tue, 7 Jul 2026 13:54:44 +0530 X-Gm-Features: AVVi8CcJFoJDWV6wB4Zw-GZvSBDzs39xzHLf0n5vGnB4tcuAmhwpJ7eKF7KPQTg Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Robert Haas Cc: Dilip Kumar , shveta malik , 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 Tue, Jul 7, 2026 at 12:10=E2=80=AFAM Robert Haas = wrote: > > 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()? > If I understand you correctly, the concern is that AbortOutOfAnyTransaction() tears down the entire transaction stack, so if it runs from a nested PG_CATCH, any outer catch block still queued on the stack that expects a live (sub)transaction would then execute against already-aborted state. If that's the concern, I don't think it applies here, because this isn't a nested catch. The AbortOutOfAnyTransaction() and the deferred insert run in start_apply()'s PG_CATCH (and ParallelApplyWorkerMain() for the parallel worker), which is the outermost catch wrapping the whole apply loop. There is no apply-level catch outside it. In fact, AbortOutOfAnyTransaction() was already being called at this exact spot before this patch; the patch only adds the deferred conflict-tuple insert between that abort and the re-throw, so we are not aborting any earlier than the code already did. Having said that, if the worry is that this might not remain the outermost catch in the future, we could convert this outer block to a sigsetjmp-based handler, which would tie the abort unambiguously to the top-level teardown and remove any dependence on its position in the try/catch stack. Please let me know if you had a different scenario in mind. > 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. > The conflict log table can't permanently diverge from the replicated table. On the error path we call replorigin_xact_clear() before inserting the conflict row, so the CLT-insert transaction commits without advancing the replication origin. The origin therefore stays at the last-confirmed LSN, and the errored transaction is re-streamed and re-applied on the next attempt; which also re-attempts the conflict logging. If the CLT insert itself fails, nothing is committed and the same replay re-does both. Is there a specific path where you see the origin advancing without the row being applied that could lead to divergence? --=20 With Regards, Amit Kapila.