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 1wWWTG-002fld-1y for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 09:40:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wWWTF-001nBr-1N for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 09:40:37 +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 1wWWTF-001nBj-0B for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 09:40:37 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wWWTD-00000001wQo-0R6G for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 09:40:36 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-36d98b9aa9aso3561269a91.3 for ; Mon, 08 Jun 2026 02:40:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780911633; cv=none; d=google.com; s=arc-20240605; b=PlDZO0p0V/+oNT4PnKUKV81sLUT0PVElaN0OIU2F/d39wrotbx1EUoPB7+ZjMnGn7u FSP1wXwUtlRLGO8l14lNe0oRIXkxY0Uj2aEDEORUdRWn4M7nPTGAcMs8vyJHOy7BuITU Apmls7HsY9MUvX9WZf61mJrd0GHqvlIOYCwZWZ0XO3ZtwE9aIVsLJtm6kD6cayp9JtqC gQKu9da500rJKnlHrlBd/EDfMPOpiVs7V4FwxoFaFS7nF33dhV4024dYaC2T5pC1EiOR NScbvqI77A7Wc7d+lQQCHmI8ThvonJVx51Nj+EeuVdgvqPejC8F/e3XB68jf3sHlp7t4 Tnow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8IGKUV5h2fq69QucB3cs4JIdwaqRWdsTyagnn8Hwsnc=; fh=vKB/AiMKyg53hHznKA4BlFka19Vgq4xgFpimz3k2e0Y=; b=YYFbT1PaORrjXjbtOTfD6CSW1ccfBZn1tF9bpyZwbmQHuiXzganTlIjHj4Lb0wFb82 9APFPhRLS72iVjlPiwa573nAexKxj2wWffoteObaHg/oECw+/r2O8odSGqpkQW4mwsyG ZxcUgMR3IAZogmA47vXlrJBPOJamdMRvqBlrY1KQNXpBQ+kQFhMyS3nXjffuUJ0exlyc YMyDKf1OyukQltW63j8APfyrRnb8dWlw/LG0Ljub1z2J15CY/2ZBMi2TsnOsLpZry9TS bQOS3xWJxuh0aKVo1jn/rZZgLAW6oFZyxH2gwaqlWu1v9Z/LgMwP4DzWqyfSZK3BQsvQ iVyQ==; 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=1780911633; x=1781516433; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8IGKUV5h2fq69QucB3cs4JIdwaqRWdsTyagnn8Hwsnc=; b=cBoV1Z9WLmOjnd5xmfmataOMXQG3WjZSQAPbOTd5d0DpwgZ4cuwgByoFtMHR0TLGbM Y0BfRp5QsCCRY4eUj/v064vvTtsP+TLeJEozcu/lzrFjKDuxmDgPrDqEGMtDFKJktalv XcjZ7QCA1yFzlVnV8v8keTDXT2r+X0Ddz2GM2fhx9bQQzzvpU0+UI03XFfDe2jGtkawL CtZ2TDeKTNrE31cI43K/xoZxd9Fz7WZ6nup3hB6UxF5m/XN1ucpktUWFdBS+BqZ01KWT jStR+VfgwO6NP04vGduYWin6MlRD8tZhf5vC9omYJBdk2DRUcLg/ei/6xEezZnuABN+/ 5mWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780911633; x=1781516433; h=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=8IGKUV5h2fq69QucB3cs4JIdwaqRWdsTyagnn8Hwsnc=; b=WtXucmn7xMK9nPrem24rHhmrzdzR+W7SxfCfD/Fk0BfrkW19Xs1FeMJOzC/rhQ9C1y /CtXOm5becq1ww2OroguQo1O621ejfelwCIbjB82ZXlIXSqSpbuwoxfK5j2Ru/aQ2ui7 n1as9S8r3+z5Xc94zKLSfHNmg7t8gcifKjM3drj4b9lOL86AgsVoZSzpGfhB7MatpCP/ 6PmfKBNWRWkYyp8RsdOHKOh1teKPXUIcX9AdWtla6AUSCmJVp36jXqcE4TrWqlfq2CMi 15+3ySI1dx/YF2ybdSkdAYZ8L9rYNtrq2hW+OjsWfZk8IbdmlYeBFA7QN0LbhHMqR9zV XPpw== X-Forwarded-Encrypted: i=1; AFNElJ/jVeSPjPvCGTLypc6D6CsicWFJbC6kjxWbx5ec2SlKkwIrau1KA9pPpe1iCtQlx+jA0eLIOqHIVoiM9QFZ@lists.postgresql.org X-Gm-Message-State: AOJu0Yzr/LdwsA39sWDUZGUeUG85/9zjnngeJeWaa83L9mnoDSwBoLN8 xLbXqwbFMkFgPW31CbfMoKhpLnNbqJ5rMP1VRoQ/05bI0WcfoR7j78PB/lJr/xOEzWyquGjMYPk CIHnIo6ci6D4QNVJm0qV6jrq84DsrYCw= X-Gm-Gg: Acq92OHaAtJAE4tF8yIUvhjugajdMlG56RM2P+MZg2dk43WiEB5gT7qol1cIOZGtX4v e+8Wd8wi7TfpaJ6FAn0ri/srctXBjnJAYo4vw6o9ggBD/1J21YckJ9AT5YOwYhWdhIeWjzkpPzu 1cgSirR6VdHmoikfJaDwxfiC2E1XJGKycCcwaU6l5AgfqB4hqZrpAcMtwdPWuDf9lD+Av9/3u2S 7KntKEU6uU3w2EH73aYsKY/2MMd24Z3iMe3flObn8SvvRywWZ1FMkpnBEOgwS5WO/CGM+o3+xPq uGrBwfXQi9Ppx5Bxs1XJOtIUYKMAHyW//n8G9yec9vjBYS1AuLOcj5mYa0xDEHI= X-Received: by 2002:a17:90b:5890:b0:36b:bb66:fbc3 with SMTP id 98e67ed59e1d1-370eec11205mr14987752a91.4.1780911633122; Mon, 08 Jun 2026 02:40:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 8 Jun 2026 15:10:20 +0530 X-Gm-Features: AVVi8CfWS5FXbJZxfxQSeHA3Qtd5aaT0VgzgwPhCeaWqNQPl3kVOOx2kftO19jE Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Nisha Moond , Dilip Kumar Cc: vignesh C , Amit Kapila , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk v46-0002: 1) I was trying to verify TRY-CATCH block of ProcessPendingConflictLogTuple(). When I force InsertConflictLogTuple() to fail while atatching debugger, I see a new error due to CATCH block. See this dump: ----------------- [27532] WARNING: could not log conflict to table for subscription "sub1": cannot open relation "pg_conflict_log_16391" [27532] ERROR: errstart was not called [27102] LOG: background worker "logical replication apply worker" (PID 27532) exited with exit code 1 [27548] LOG: logical replication apply worker for subscription "sub1" has started [27548] ERROR: conflict detected on relation "public.tab1": conflict=insert_exists [27548] DETAIL: Could not apply remote change: remote row (4). Key already exists in unique index "tab1_pkey", modified in transaction 793: key (i)=(4), local row (4). [27548] CONTEXT: processing remote data for replication origin "pg_16391... ----------------- 'ERROR: errstart was not called' is raised perhaps due to 'FlushErrorState' which sets errordata_stack_depth to -1. If I get rid of FlushErrorState(), the internal ERROR is not cleared, which results in the worker exiting (which we are trying to avoid). ------------------------- [30031] WARNING: could not log conflict to table for subscription "sub1": cannot open relation "pg_conflict_log_16391" [30031] ERROR: cannot open relation "pg_conflict_log_16391" ------------->this needs to be handled. [30031] DETAIL: This operation is not supported for tables. [30011] LOG: background worker "logical replication apply worker" (PID 30031) exited with exit code 1 [30043] LOG: logical replication apply worker for subscription "sub1" has started [30043] ERROR: conflict detected on relation "public.tab1": conflict=insert_exists [30043] DETAIL: Could not apply remote change: remote row (12). Key already exists in unique index "tab1_pkey", modified in transaction 872: key (i)=(12), local row (12). ------------------------ I am still thinking how this can be done cleanly. Meanwhile putting it here for others to review/comment. 2) Also, I think InsertConflictLogTuple() in the non-error path (via ReportApplyConflict()) should be wrapped in its own TRY-CATCH block. When I force an error during that insert, execution falls through to the start_apply CATCH block, which then attempts to insert the same conflict record again via ProcessPendingConflictLogTuple(). That insert fails again for the same reason, causing the apply worker to error out. Should we keep this behavior and allow the apply worker to halt on a CLT insertion failure, or would it be better to avoid disrupting replication by encapsulating the insertion logic in its own TRY-CATCH block and handling the issue locally by emiting it as WaRNING? Thoughts? thanks Shveta