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 1wbV48-002cDW-1U for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2026 03:11:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wbV46-0048qx-34 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2026 03:11:14 +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 1wbV46-0048qp-1s for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2026 03:11:14 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wbV44-00000001gvB-0xuC for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2026 03:11:13 +0000 Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-37d826e9811so286649a91.1 for ; Sun, 21 Jun 2026 20:11:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782097868; cv=none; d=google.com; s=arc-20240605; b=jYQUReb0Lh7Up3RvwqdlLVEjiSwpRrpeuBCk/ey+B4NpgpYJAIYrgsN4Qk86H46tyu IPXSOMfhdOB2dIhTY3nrzJbtSvb6CLA5oZEk+lGl766uKqMNBqY+ofRxHE9iMhs6pgOA UTNw/6yqaZ8mEO7siFP8PMw0NZspstBOddxL5dqXZsMLNcodsgb9bJOQMiKAUGiqYIU5 +UBfw6mSQRe5LvpJQdLTFTTWQzYL0bxrMYFwlKwmrl+Uf7zkpaYPYa9kTnZRMk+zBziZ wyWIK0niXU4qWGvhizNdpVupCrFAHeNiVI2bwUh+7Ajq8ewasEbYj5NL6AW1CrlVQHOk O5Ig== 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=LKHKCBmxExDvql/xEDsL9fhz1F6Bw0LhG17Q7pX1Y5o=; fh=UcUlQ7ZGLBt8ia0EBUybJYROoZskcFBszXlBgsm+gRY=; b=RMDZrVJhHNpKDMBPPnQY/2DQDgBUKb9aq83OVWmMRrWFxwFa+wfkTYpUXFkdONuztn iZlvBK49+8FZ/UtM7SwnX0OFFQSdzEzw6j91w6VF0hyRrma+qvZWFvKDqvGRaCJPoK5V jRFrxhc4fBnyqi1weuBHdQOFXzoDS/Fm1motaocZt4AntKip2e0/hY0pGCH3RUF44/w0 eQVuOkffhvDGMqY5EqxRzzhD3L1RnO8HnLrvt1gmV6s6wR+G2j8jOHK/Vu8CVQMV5rmC 6jAd5gJcEWfKmUxaEU/JTmbjJP122DLP0bDsU8/Vt8Fp/LWai3E6QaEQtNyztJjNEDKJ dhTw==; 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=1782097868; x=1782702668; 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=LKHKCBmxExDvql/xEDsL9fhz1F6Bw0LhG17Q7pX1Y5o=; b=bTA7qHIL8HS2QMWDWpfRmqvhbzbHGCuYrtyHsJ0kvakqVo9iMkS0gIMC57Qb6Tv3s5 fALjPcfAW1aqu8vK8MSCEp3CMad0igS+8Cj9S8RpAYHK6dYJ0P628eRJq81bKt7eD7YZ Ig/nDrzPFSc7LeYBYIVfeKqv1H9OTuAYmOyke4aKbuVqCHteABIeTqwBjcIdgtjU6wvg eaUaE7IxcDZEucqSx6ZrOWvbJqYLubbXBIUY+D8Lg8GFHuR1Uw4pz2ZYmncqm7gCrRGA 4saUlkmoZf2TGhJzCMnC/IKcYnosEdq8UIdcnqjT6TXCL9nVDHlub7IP4hdhJzNoiiNZ RNFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782097868; x=1782702668; 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=LKHKCBmxExDvql/xEDsL9fhz1F6Bw0LhG17Q7pX1Y5o=; b=jK6KFu/nXE4VK7GBnGkJtRz/VT7RbyHuGfwrQBljw+E98cgW0ElY1vfFx4MxrWXFmX KvZeNntvlAZ+s2YgNqLSO2XFXnwkEEQqV9rS/ULSFaEdWWB/DIh1PrZxVAPWB3XTITXB 4ywJwQP0hKwFh4EcpUwo2U85KoEDoYn9Hjs/opcdmPnoWQDINFDblYiPrcVYrcZN5AZF mwUofgLIcrOF33mhZMdVeQKcbfVUT74EYlsv3BXKhFAQ0bWFDWPOcOh45vSKr91DAQLL iCIY7bfGNx52cRvBdv17f2g7DjGrRVQfpof9NK68L0xoDOBxkFHIpADoW+SpuNnAIAI+ rvNQ== X-Forwarded-Encrypted: i=1; AHgh+RpAucTAdKeHj+Lj8dn3rY6fvpKm5k82Rb3SOoNP9xE3eiwDQvRwNtAZOpvAhgwrNqZP2HAc4jAT0R+8ZPJ8@lists.postgresql.org X-Gm-Message-State: AOJu0YzlDbS3RrG0o8qDPtxJIPqH2cYB35Aq98PO8F9U4aUD3VC8bVdy FDvIxxGPYD4gYVDsWwfqiOmDDxM7Ixs2ti4IIlz3ADXEqHIziDD+TjeGmWOEgZJZSw6NXVe6htS x3ElKU/qEXMQj/WEAz2F2b6Uz4CxyQvA= X-Gm-Gg: AfdE7clKvaHyASfXdjMZg54UQW4Q9Zjxv6G2rIVdZ9nzGjPrmGYcb3H6rrbzmzlsPTm alVqJtjkLvl+Zsi34x+qeHGafUGMlHF1R1j4h/NaxFQg+l87AxF3lZNuxVnXQ5pA0ZT31mhHJ8F 9T73jN7eqHWWgEqq595vku/GB998T9TL3NXGSYyELY9Rw1WNlbXvznf1ptTHz3mlyCVoxBwT1cL Z2USc5pi/iFBK5gUlAcyvVV5gkc37CU2GlCsklUAKV1X0Q0nv+WDpivWMuNIR+cz4D6i7rqZgAv 0J5W8IjFWPZ+jia9LWeBSb1LuhuIDN95GUmU0EtU1OtYuhDWDMep4iPkvMmv285pCHB1PJQXYVk jbstlh+nu X-Received: by 2002:a17:90b:2d8f:b0:36d:70c8:3a1 with SMTP id 98e67ed59e1d1-37d15e678ecmr13994137a91.13.1782097867801; Sun, 21 Jun 2026 20:11:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 22 Jun 2026 08:40:56 +0530 X-Gm-Features: AVVi8CduMksPEWIc70YdArwIF06CzWeWJ1pq8ZMuwxiRRDzurdmKkXkc2Xz1yAA Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Dilip Kumar , Shlok Kyal , Peter Smith , Nisha Moond , 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, Jun 21, 2026 at 7:53=E2=80=AFPM vignesh C wro= te: > > While attempting to log a conflict, a concurrent ALTER SUBSCRIPTION > can change the conflict logging destination from all to log. In this > scenario, the apply worker may already have cached the conflictlogdest > information, including the OID of the current conflict log table. > However, the concurrent ALTER SUBSCRIPTION drops the conflict log > table as part of the destination change: > +Relation > +GetConflictLogDestAndTable(ConflictLogDest *log_dest) > +{ > + Oid conflictlogrelid; > + > + /* > + * Convert the text log destination to the internal enum. > MySubscription > + * already contains the data from pg_subscription. > + */ > + *log_dest =3D GetConflictLogDest(MySubscription->conflictlogdest)= ; > + > + /* Quick exit if a conflict log table was not requested. */ > + if (!CONFLICTS_LOGGED_TO_TABLE(*log_dest)) > + return NULL; > + > + conflictlogrelid =3D MySubscription->conflictlogrelid; > + > + Assert(OidIsValid(conflictlogrelid)); > + > + return table_open(conflictlogrelid, RowExclusiveLock); > +} > > As a result, when the apply worker later attempts to open the cached > conflict log table, table_open() fails because the relation has > already been dropped. This causes the error handling path itself to > fail before the conflict record can be written to either the conflict > log table or the server log. > > In such cases, the conflict record is effectively lost and is not > logged anywhere. For example: > 2026-06-21 19:31:13.592 IST [263598] LOG: logical replication apply > worker for subscription "sub1" has started > 2026-06-21 19:32:26.731 IST [263598] ERROR: could not open relation > with OID 16405 > 2026-06-21 19:32:26.731 IST [263598] CONTEXT: processing remote data > for replication origin "pg_16404" during message type "INSERT" for > replication target relation "public.t1" in transaction 698, finished > at 0/017D39A0 > 2026-06-21 19:32:26.735 IST [263471] LOG: background worker "logical > replication apply worker" (PID 263598) exited with exit code 1 > > Ideally, failure to access the conflict log table should not prevent > the conflict from being reported in the server log. This issue is > present with the v52 version. I have not yet checked if Amit's recent > patch posted a few minutes ago at [1] handles this issue. > There are two places in the patch from where we LOG/Insert the conflict data. First is ReportApplyConflict() where we LOG if the conflict arises from a non-ERROR path (aka conflicts other INSERT/UPDATE_EXISTS). In that case, the conflict data will be logged even when we fail to insert into CLT. Second is the place for conflicts that arose as ERRORs (aka INSERT/UPDATE_EXISTS), where the conflict information will be logged along with insert failure as CONTEXT. Can you please verify your test based on this input and share your findings and thoughts? --=20 With Regards, Amit Kapila.