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 1wa3y8-001VON-22 for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 04:03:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wa3y7-009EqB-1r for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 04:03:07 +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 1wa3y7-009Eq3-06 for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 04:03:07 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wa3y5-00000000uWt-2L1I for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 04:03:06 +0000 Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-c88cc025f54so360035a12.1 for ; Wed, 17 Jun 2026 21:03:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781755384; cv=none; d=google.com; s=arc-20240605; b=PSURX+6lbP9jb4zwmR4d4xH57FXagk/HTwoFbcf05UlvmTHmsmD4Aq1lcHSOsl2W0/ cxYrUrG9J2X2Ummx3UG/Izml8gE67W+f4EDuCFXFCOp7/3soozSTVClNkhALVzYnVket YfTfTvfBmGdHM99OX/WiA6zx/cMlUvie2Y4I6EReV9pHqyBXhW0MPr/LF5yLqR+P9+L6 w3g11SojmxW2Z6yzg4fJyPXZsY5/uk4P4ZPJDmaMxlXa9YTMGSQn3ZbrvbcrqTWsl0k8 8QyHW91O9LDH8kJf3u9tu3eS9KT2ch7hIKdnI8EidEbylI5QbHj50xxJrKVQ3X3DxZww uOxg== 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=D3fgtssJvyXbBdSeCZ0Ie1AuCJrFNtUHv8fDfxFtPLE=; fh=909iYUM/k6yU4KkKJvqh40Mg9UyTaC+A/7MJceDrHLk=; b=OkfNSLayJrKetn9/Ieb/QgSd47VV9fun3zpir+KTGc8Qnmg/QkIkBk9ruVEyGPLORn bswWKscrAY1VQbkF1235Mxx5c9BCReyOvFqBhoDE2rhDXeVJzh3fMCxgU6/YRpFkZ5h4 2BJ6V4ipMosWKp+mTPBYSCCKf3mFtRrFV9u6euDmTATYA1zLLT3Yhd+ugnbwllNhdSzy JPixCjyEb80qMhKQQ+3O5PnzsMcZHJOlnFmUBg4F5dl5EQrckOqi9W3ke3Gob28d/F/O FkQQGIOzGfTz/g/vBMohx3gEFZaDBLVG1bHWSjDezDiTywBRYcD7n40AQ4b85mXbVzkx R10w==; 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=1781755384; x=1782360184; 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=D3fgtssJvyXbBdSeCZ0Ie1AuCJrFNtUHv8fDfxFtPLE=; b=LGgGjjwLhtvTGQA5GIMwFWV5UNV67nZrdJhj0r8QSNotLBK5yq2NjsGmXuGuhCe4oV jI2jYNbECrf7C6xZKo/tcdQ/52d4rKSkc3dBMsHZ7tqyUu+8x3m0XEWbZDZZEBWBU/GU HWBC/SkRxMHUWGNqzHPWD/VPZk0mOlqeu5y1Anrnr2uaRtTwgxeG3LMUab/OhHqlOi3m rT8BaTtt+S50GjxqlHJObLQFlRN+04/0KrT3nt9F4TQeTSyBgFJVN4XkwsJ/Cjx99NJ3 nzmmGmb+3txjcMjC3fYJ1UKNn2HQF8qFaCg39wIkHuxCdRoMStsagfeUN1JMyZjZuNWr KUPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781755384; x=1782360184; 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=D3fgtssJvyXbBdSeCZ0Ie1AuCJrFNtUHv8fDfxFtPLE=; b=Rv1bRLt4pWISDSD+lR0LbjM7pJAjsuJYN4RlGKybCfl/0MD6uZp4608WHcQgN6Iyzi YHAwcsf8Fl/1mFENyjf6MVkXT/EbG2B06jdxt7fvju7Lf8+wgj8FA+4PjT01lm5Pn5tV F/fQkODXSHJaz1P4vvZbz3j9B8g6We6WTI6Jl4SP8utbuaxfVMtWKcRbTBrg0HgRLe4Y EcIfoYwsV9+u2Ogai2sHsUQysg6YzMpU/FZju/AK0/FRy+mo6GR+ZX2j4RMY0rEc4pGn Q7R4IQu9WuzV62udxHZZXLabjHjIPEKpRHwSYdDDXj0FY3zw2Ss3Akwo8cuYPL0sgror jgLg== X-Forwarded-Encrypted: i=1; AFNElJ8bqq2bHsj/yrytns8F/3elfH2Z7lyLJDpfBalHlKGplqchxTVfOPbpq2C8Hdw0wfiQ86fOAQsk6uhoZMzK@lists.postgresql.org X-Gm-Message-State: AOJu0YzLmBZrypHD7bkMZEG8+tR6IueCjkbEgh5WSLZ+c7eQHPhOILej J3mzeSw12NQG1iOp1La8wI+RLW74Yhul5EiyTqq+GSiAFYaNJPtGWgHTY5H8fMoKH/MCCbYRHp7 WdLAjVH+XZoJ4zhsnJVxpXPakp+/Jn+A= X-Gm-Gg: Acq92OG5Nra+tJIxTWxIozfXluizSDsO8JvbJxWDmVAaNm8vgQQL9F9kvqpP54hYELo 6HTPGlsh87UYapJIL/Qj401HoaVapb9qZf+mJmI493HvRXwBIpyHjlccnNdp9geWGK43D88zcr5 f1mZOfTdrs6xe3QtDGUqM8C36fVyYYYh32Eg51N4v9Sry6b14eufjXSNgfMy78X6gC0sqmghFzm +ilmK7GuPtzlJsoXyXVf5mnDLG/nO50yxzHLaw9tTwGQAkkqcBReen7qPWd+DcBr3aqljVsSy6Y Zh07oqIBR12icai+bjc/krtTpYK0n6urtF8PJJw/JQ== X-Received: by 2002:a05:6a20:7294:b0:3b4:895f:6ac7 with SMTP id adf61e73a8af0-3b8be9b03f1mr7855820637.22.1781755384102; Wed, 17 Jun 2026 21:03:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 18 Jun 2026 09:32:52 +0530 X-Gm-Features: AVVi8CfX2Zw_gYYHlV9-50a0Kybqp3GiVGMuT1-b8Y40fbI0Q6-TAQY9JElvnXs Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Nisha Moond , vignesh C , Amit Kapila , Peter Smith , 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 Tue, Jun 16, 2026 at 6:54=E2=80=AFPM Dilip Kumar = wrote: > > On Mon, Jun 8, 2026 at 3:10=E2=80=AFPM shveta malik wrote: > > > > v46-0002: > > > > 1) > > I was trying to verify TRY-CATCH block of ProcessPendingConflictLogTupl= e(). > > > > 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=3Dinsert_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)=3D(4), local row (4). > > [27548] CONTEXT: processing remote data for replication origin "pg_163= 91... > > ----------------- > > > > '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=3Dinsert_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)=3D(12), local row (12). > > ------------------------ > > > > I am still thinking how this can be done cleanly. Meanwhile putting it > > here for others to review/comment. > > I am able to reproduce the error, I will put more thoughts and propose > the fix for this. > > > > > 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? > > IMHO we should just log WARNING and continue the apply worker on > conflict insertion failure, lets see what other thinks on this. > I have the same opinion. Allowing CLT to block the apply worker would be undesirable; CLT is a history/logs collection feature and should not interrupt core logical replication work. thanks Shveta