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 1wZTmJ-0014Y0-1o for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 13:24:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZTmI-0006Sj-1M for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jun 2026 13:24:30 +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 1wZTmI-0006SZ-0C for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 13:24:30 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZTmG-00000000jt8-0PNs for pgsql-hackers@lists.postgresql.org; Tue, 16 Jun 2026 13:24:29 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-39677234558so40769561fa.1 for ; Tue, 16 Jun 2026 06:24:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781616267; cv=none; d=google.com; s=arc-20240605; b=K9C2W3MfJ6fcA0fQwaO7ICUs32XeO4HKaxIKW/ViVel4zBGlm2O9L/8j4GXL9CF+Dt 5xcnacWWb/G1bbN+WkXU75S9CSRltT6llM+WFZIyUbwn1rtYgsUyXd6aitluPPuGR1mV iFpFXHBCz/paovktNBGgtdSiITTcRKO7yWvOE+hQMeqjhlAj01rhitfknOMzAWbfbpry DL1B1GvuTwuJADutGbHlpZU73wwLhm7c7iqLwv85X4oNzFFTbwRinV+GBU7IY13X4Qmx +gXyU6lTe1dIqsxHPIXGpWn/HiVcMHHypFwJvsLAsLXTX2+TFC8YyR2idnVpFCM0xwXf nljw== 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=iBu6HwsZ505T0BQN7z0eS3t5uG0uBe+TYpH/9RdYnec=; fh=SYLDm2dCAny6UpSk9DlWN66y8iSQ6NOZZyQkRGvl8XE=; b=C2DZCHcbbofBK3Xb9bU8+rvga9WPkGGXFS2GVqakMt7m2QH9UWv5uHhQ+VbESHRUuj 7utiH9AAnQVu/ZKERgKJCn1gQGO/GUmtkv4GL/0sPjfBYbmMCWVyfUoOs9DzthNcX2Vd s6fpL4/+uSQr4pZmqBxPkuAw9k9Lse6Rm0Zr47/ehxiFJ/G5oOqaoEtLCNJ05Y4EnmdV AdCep1WkBOQuXgLFz9eAixY++D53yUNYSSaJQrRD6QQjhX0HqmPGuHo9A/B3UWAcwoCX YA0JpdCBmcK4Vjc7z6+qFaUoe6Oc7xqAuzWFqkGOhfPOaZEZNd73x5VyslygFDqfjYgo xUjQ==; 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=1781616267; x=1782221067; 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=iBu6HwsZ505T0BQN7z0eS3t5uG0uBe+TYpH/9RdYnec=; b=tNfgnvsRbD287rClmMpY6EhfDJ0yh+qTGCh0i/GudmnEzgpx4cDf5ptK4NvidpSaCj Pc522G61bHUI7NNM/nSmnCO7Vq1Q39cCCoenmMiUeGClgHQwL8djc1MnUVoBczH4BUKX O2tIoaalB3EVoOVJarfD6kiMs/lz+ZlexMf/ZpNva3P9TukkfW5wMFmrLsuMJeQFBN0I 833QVfWJRToWxPltVvD8vVyRx00GqqkhELwYTCNdlkcX2Ajsn8rnWVr4fOvR0k5I8mnh v5OrdGoChBBFoPvUVno2kA9ZRsZfuC6e8spKWspTMlmJhmT7A4OHuk0MdWY7/ozyETNO hk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781616267; x=1782221067; 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=iBu6HwsZ505T0BQN7z0eS3t5uG0uBe+TYpH/9RdYnec=; b=P1A83T+xKTw/ZW1RSzflUKA9HO8xWQs0m5U+t1ySinmK+mWg1iOprXc07zG7qFU/Fv RilQVKhA3U5zafomiTUzQFl9M3fp3O5zF3siuKN6WBOjyU4Dkq+1Jy5rM2JWFfMchGzH F2nrShnRuECneLeyUcDrmG67aJ2vfDlv/Sj8Y6MSJjhEKHhTpD6VoBLtQIb+5SZFEQQ4 baYeFZzhY9A0LnAxol5wcpIeWpSq1ByvrD9h3VbzOTIzM9fRBfzGh2GTY/TpRbpP8mUz oCkpLvVcMbNNvnIjM+g4aX+j9MXeKN+7ZuHRMpX/NYLBg4rsQYuPOu/bZdWxODjL0vKd FlTQ== X-Forwarded-Encrypted: i=1; AFNElJ+N1EoQXjhk2lhZ8NQNmz79jR6plqq0ZmvN6Yksxw4FGW+om5MhLV4upIFkWTCZu23qf7MkzzhzqxzvMgu8@lists.postgresql.org X-Gm-Message-State: AOJu0Yz0iuaB6BheAEODsG3dyFFtWv3/5CQoRelNzQRnbY8B5JY4nbnH i7dMUgtwyeABQiPu8dpfMwkPJglyez/4PvUzJ0CAm6oLL7kFk7NrsNkUgiq3NY7iwTrcUaWTRJM /XMb0hB+OhggU7ox7V29Ir9dzQ66Gn88= X-Gm-Gg: Acq92OFbvpSCrHe2/dDrRrZy6ScA6pXf4pKICKlF8zmbY17936jXfOCVyJyMFZqBY5Q 8HUI45wTFRSb5UCvLqn75ToR0h2PxdZTLtpJxFEjpulwj1DLxaPei3r7ffnGG6HIpD6zOA7sYiS i/w02LgG0qRXUlTzMo6GhzvQz8BqaFNEzf8466EW7ZF9gN3MKoAucsuNqFlGQkSC4kk1NqrlCck 9D0NoqYNDlJh7PCt0WeO/9wLthWpefSWR0ANTg/l7ezpOk6zR6Lau+nkIBca7JSR7feCkchI/Ma sAnAYXQ2WVrPrOLItTn9SnvsLgzbHxu445IuRsk= X-Received: by 2002:ac2:531a:0:b0:5aa:6ec6:2579 with SMTP id 2adb3069b0e04-5ad43761da2mr935200e87.43.1781616266649; Tue, 16 Jun 2026 06:24:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Tue, 16 Jun 2026 18:54:09 +0530 X-Gm-Features: AVVi8CcB2lWqbCO9uUNUIGA9110sEwdAGhvlEINUDNYpc6LouAcCMOMKLCiiFzQ Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: Nisha Moond , 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 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 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=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_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=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. --=20 Regards, Dilip Kumar Google