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 1wWWBZ-002faa-1p for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 09:22:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wWWBX-001d5y-13 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 09:22:19 +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 1wWWBW-001d5o-2X for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 09:22:19 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wWWBU-00000001fCR-0XLO for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 09:22:17 +0000 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5aa68cd8dd3so3661316e87.0 for ; Mon, 08 Jun 2026 02:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780910534; cv=none; d=google.com; s=arc-20240605; b=O3a0qvGd/7iC5btxMESNFpDjVaPew1e/T5oY5/hNPrwgkbaq6FglZdnFH1b2Ia/EFu W90skohhPgkULFC7apALMQiGuSitBaodTJj1OwblAmjMzaTKSmTa6P3E5AvoJhKbYJ8B PLP97IMneIQGLPULmNYk4bVHpCLCh2nsX4yZnpMr4+02RvenMY4sRlThRyC1qQFldGTa CWkJ0CkHmA0tDVKMd98xeWIt8NyEwwYaRrbbdMI0lVJ6VUf5AYdncSe0slme2DHoNnA2 V4UxQw3ArOQGrV50WCXk9YuSP5Fctce43lEv/6spclGsEMVU0yv6mgYbQ2vsAEQxbV96 4+hg== 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=pfHZ3jK3ivcyDMDFSVpvP4g0G0gtcqzz+BoQlXEIob0=; fh=tBbsMFE4qNXhj2FV+OB/ZMfapuG83oZt6pKQQOxLG7E=; b=kG+idoGKsJPRpOVP5zecPxGvJsaKTYV7gytVPEGaNyA30oLSJWLslrXemhF2nLZIL4 FMxiaqqnSgOUZpZ67eCL7WY9RaQ8f4dqO84torD2J0tvJBRdVS/EvGBixhXUVKYnGVS+ oW9w8aRwp6CuYtsPl9MjtbmBTTXgd6wyLFIdIqXerDNEfoQWDN2/PlvujJDFa5Jnp4nV CEMEX0fwFTHzHUMVwFgUo4QnC/fiSmw8f/r6HtIFQT3VayXYbO1GBB4FhgSLn+W7MEWt s2q+Ved2tXXHf0qNxB0zy0K6lpkvcFrfrbRTiQGaCJ0FAOciR/7MgtNBJISGhUgnUYqs ZP4A==; 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=1780910534; x=1781515334; 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=pfHZ3jK3ivcyDMDFSVpvP4g0G0gtcqzz+BoQlXEIob0=; b=YhQoixisAuMvGGWkk26Hzwou2w7AmtxU1Kf0gspLwMbzICnek9mVS1SCq2E4GIkRwk 0ypOlLpGv5IJKKIvnoSFiK2+If/bYR+48BMtNP4QDtGRoXsHYHRuA7/WGc95HngTdp5y iMf60KqODanX6Xl7FajYkLk+W5mlUwHegRZ26CyGZtWRWTRnYxzx7ITOmg9AdoVAIWtt fPmV3PCjmHWEEBFgA98NInBkZI0wGIDcbgtGOl5ycj00roZaiYG0h5GwRZQto7G5jsZk KuqXzyAu/yw6TP6bSt1XxYoTpGFO2NH7ykBD8oHDJLE1vIn4vn/cp4eSwejJrLWZ8rrX xUZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780910534; x=1781515334; 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=pfHZ3jK3ivcyDMDFSVpvP4g0G0gtcqzz+BoQlXEIob0=; b=Lp/03M3E1pM7wz/xOolAdJBMfeLTbc2ehYqX4PmdkplBbjpQjLZzS1czDANvTi79Su r0UTNobXad7slxplr8aahbY4MWbA/vXJaArO2lsZmLdlwy3hrGF5JYiwY2P0gb9rFu/t CDSJGP9/fIDySpjoOrnBQ1U+cj+6CW/aHQpPBLr7WwpeDnre/oVAZMu7faNsGo5XamNt 3knIHxf1FIuNCQ38mivh7+oH+WmKAEK7ZaNb5ZIi2wmkqMuQrUO7kWR0X+dUGt1xNm8Q CXmOAQ19k9bax+5NotEAawLNJHKwj97nn2AVG04p7DbsICV1WFB41KSHWnmTdzXeymYK noXg== X-Forwarded-Encrypted: i=1; AFNElJ+clAyH13tds0MKGUEZ8KOrwR5qP1lI42LnM4Djp612Gd6go0CprUoWBxnb9TR9TR4UmfYYi5wOKbuqkeJE@lists.postgresql.org X-Gm-Message-State: AOJu0YxWDPYHATEjuqRyXevEGApYsD7DVx7ToVpqA0eVwf/00e1KU56o glQ1crBc+7S8x06Z6+0YyLfg3o2Mh/BVyuIpTupskc4/VVwPRLPQwTY/eFQ+amM+TmdSLsyAOln QaDbaBtxleWXtkJnjL5ncxOgEbXUgiQ== X-Gm-Gg: Acq92OEAnXHirbAvTld1EjFE655qdyEBd0i2AUH79ECGkGrvUbtIzOyYcjHYNYhJ0Mg 1dmi39P5YssaQMKrY9JC0d4thGgFGflY3Of8zf8j5J7upHAOisQkYEYveUlNwUjXLFlwPeviLa8 JHMjYwxZPxPuqNY7K0Mc1fNvrYGD5+xyZE3AftSFAvwoQ4Yink4TroVeDDe5owM11MC9OhDqGB/ i23A3bw+pD2C4jPshC83SSUh/tjyefmdJrcswYAvMs/j4y+lopX1pSLfb4Hi3C0WqSROrSpTm66 14C3s0q5R885r+nNr8nH8Whf X-Received: by 2002:a05:6512:6c1:b0:5aa:7126:c62c with SMTP id 2adb3069b0e04-5aa87b40d20mr3996596e87.1.1780910534125; Mon, 08 Jun 2026 02:22:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nisha Moond Date: Mon, 8 Jun 2026 14:52:02 +0530 X-Gm-Features: AVVi8Cfvzq8WSka4U1ST89YcquXi7HK5egJCxjnO8WT1w-beCwIrnTalDPQvDPE Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: shveta malik , vignesh C , Amit Kapila , Peter Smith , 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 Fri, Jun 5, 2026 at 4:22=E2=80=AFPM Dilip Kumar = wrote: > > Here is the updated patch which fixes all open issues except Peter > reported on 0004 patch, Vignesh would you take care of that? > Thanks Dilip for the updated patches. Patch 001 + 002 1) Issue #5 from [1] still appears to be present. I still see NULL values in remote_commit_ts. From patch, it looks like remote_commit_ts is updated in v46, but too late in the flow. I tested by moving: /* Set remote_commit_ts for conflict logging. */ remote_commit_ts =3D commit_data.committime; before the apply_spooled_messages() call, and remote_commit_ts was logged correctly. It seems the assignment needs to happen earlier. 2) CLT reports NULL or stale remote_xid for two-phase transactions Test case: setup : pub-sub nodes with max_prepared_transactions =3D 10 to enable two_p= hase -- Publisher setup: CREATE TABLE clt_test (id int PRIMARY KEY); CREATE PUBLICATION clt_pub FOR TABLE clt_test; -- Subscriber setup: CREATE TABLE clt_test (id int PRIMARY KEY); INSERT INTO clt_test VALUES (1); -- pre-existing row to conflict CREATE SUBSCRIPTION clt_sub CONNECTION 'port=3D9933 dbname=3Dpostgres' PUBLICATION clt_pub WITH (two_phase =3D true, conflict_log_destination =3D 'all'); -- Trigger a conflict via a prepared transaction on the publisher: -- Publisher: BEGIN; select txid_current(); INSERT INTO clt_test VALUES (1); -- will conflict on subscriber PREPARE TRANSACTION 'clt_bug_test'; COMMIT PREPARED 'clt_bug_test'; -- Check the CLT on the subscriber. The publisher transaction was 699, but the CLT contains: postgres=3D# SELECT conflict_type, remote_xid, remote_commit_ts FROM pg_conflict.pg_conflict_log_16398 ; conflict_type | remote_xid | remote_commit_ts ---------------+------------+---------------------------------- insert_exists | 698 | 2026-06-08 14:04:34.903284+05:30 insert_exists | | insert_exists | | ... It looks like remote_xid is either stale values from a previous transaction or remain unset when apply worker tries again. The change below fixes it. @@ -1300,6 +1300,8 @@ apply_handle_begin_prepare(StringInfo s) set_apply_error_context_xact(begin_data.xid, begin_data.prepare_lsn= ); remote_final_lsn =3D begin_data.prepare_lsn; + remote_xid =3D begin_data.xid; + remote_commit_ts =3D 0; ~~~ patch-003 3) alter_sub_conflictlogdestination(): + relid =3D get_relname_relid(relname, PG_CONFLICT_NAMESPACE); + if (OidIsValid(relid)) + { + /* Existing table from upgrade */ + Assert(IsBinaryUpgrade); + } + else + { + relid =3D create_conflict_log_table(sub->oid, sub->name, + sub->owner); + } + I think Assert() above should be replaced with an ERROR similar to the one in create_conflict_log_table(). One possible scenario is that a user manually creates pg_conflict.pg_conflict_log_ with allow_system_table_mods =3D on. In that case: -- Assert builds will hit the assertion. -- Non-assert builds will silently skip table creation, and later CLT operations may fail in unexpected ways because the user-created table definition may not match the expected schema. Before patch-003, create_conflict_log_table() correctly reported an error if a table with the same name already existed, which seems safer. 4) 002_pg_dump.pl - WITH (connect =3D false, origin =3D any, streaming =3D on);', + WITH (connect =3D false, origin =3D any, streaming =3D on, conflict_log_destination=3D table);', typo: space before "=3D". /conflict_log_destination=3D table/conflict_log_destination =3D table/ ~~~ patch-005 5) doc/src/sgml/ddl.sgml + direct user manipulation. Unlike pg_catalog, the + pg_catalog schema is not implicitly included in the + search path, so objects within it must be referenced explicitly or by typo : repeated "pg_catalog" It should be: Unlike pg_catalog, the pg_conflict schema is not implicitly... ~~~ [1] https://www.postgresql.org/message-id/CABdArM5N0LgkHc%2BJOKcbDjpx%3D0hd= WDx%2BJ7y%3DUS2apEEmi07oyw%40mail.gmail.com -- Thanks, Nisha