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 1wd2q1-003qWU-2a for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 09:27:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wd2p0-00A8sc-0K for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 09:26:02 +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 1wd2oz-00A8sU-1N for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 09:26:01 +0000 Received: from mail-yx1-xb131.google.com ([2607:f8b0:4864:20::b131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wd2ox-00000000JbI-1cXI for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 09:26:00 +0000 Received: by mail-yx1-xb131.google.com with SMTP id 956f58d0204a3-6603d8697d2so670752d50.0 for ; Fri, 26 Jun 2026 02:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782465958; cv=none; d=google.com; s=arc-20260327; b=MO/5FVV6M5SyNfuM20zmff0983/MGhw9paQxjnr0VWqGWsQnGMI/JxdL6Z/PwRMvYQ ehC0XaopPatQsKaD8rCbRpd78FK5AS99A6l2wIXDatQUkwzLDlqmgOViR+XflJBq2Rmx h+M0DR2FQDxzDz0/dW8gAmGcn/QyVYV3tGb3bhXBVJvwjDDYzpbnobVVehTVSvFAdBcU 6C5zLhOe2dV0TEPpyBe+ZsRHWep7vvyc3uP7e95VO/pZjpke5e5RgarbA8dAyR+pcm1y ywtojOMlGstcKXZWoB1N7NYLUcPdJXfewrEVuKxMLSW35i4v/+HuZyy6FYlW5tBHsoV/ qxWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IFaGOwjgp1amQJ3vvElr6s1CYX3c2f88gxYWYv3pL+Q=; fh=Z4DdMaW9YMrBLdDScfZp1Idwh6NDxs06/Y2zQOjdx2o=; b=VvY3nJ/KveAH4fpCsWU/iDtcZdsB9gT3afxRhoxsM+7HPprsbZuErXQvaJA/NUNArj wcanpyu8/JIPITSMIfGmTeoPU7+op061V/PjOg962TraHHfU1fK9VC8sxsdA6Ou2JK9Q +STiNylNPmoJAsVP8JxhK5Q1URCpXhYHIysmeQjL86z2zb9f3/w7U4ZGHA91G9JEO/4K HzEwad3Hjo6MY/vhzUDZZ6+4njZULg9S7SDBkh2b+ImNfAbE2U1OCFpcfs0jBrm7hoFz QCom4f633VMRLZc+HdfRUzQnxgducOf4HU0gNEDbWGBuhneiup5NbWU3Q99DitU1/+0J T/JQ==; 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=1782465958; x=1783070758; 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=IFaGOwjgp1amQJ3vvElr6s1CYX3c2f88gxYWYv3pL+Q=; b=kZS68XAmKmGgz1EQN8UKm/IfoReevRnj+lxO0tVo1+dAFQLDfic3OlrQWoCMoXeAVN LkE7KLLyKwpfsO2v3ysOWUnsPG1DHFwUUXdSvifoaoxPUPC8cLMTiwzLXydBr3PU795k RNgovOSFxsCizUqkoDFmpKBnIs+4qk4JvsLWEyIT0k+Zb1O6iNCyWZEz1e29mJClm3tz 0TNjKSoOZV15QJnFzwW0WnYOxqde2LkPyMoY9VeARX1ETiniJ4jvXc7P7ESf1r13G1iO kSWbm9AmUf0BD5c+pTCSNs1HN46FnVpqpX6hrEE5YdKqPjZK2Aczk7XnqnsKRPoM0DbM 1wCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782465958; x=1783070758; 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=IFaGOwjgp1amQJ3vvElr6s1CYX3c2f88gxYWYv3pL+Q=; b=nBJfsGczPB9RegL/WVZcB7YFf9+ivhInLf9AEi3B0w0chIJZXvRyHid5GpdsjtJmyB O2si9U80qwVii4mUL+i6LzfbSnoABZ6I4E0upwVu/XoRbEPwqOblIN+oW+Zi6OptZwfh FfucOKDsG2mZayt8RryzmZvdpU/TueKKOrVNlKtA6MDWuSP2kvbDvPX+6WDC9iE80JqW aXol4QyWT9grA0YA8A8Mt8eZeBuwLpDcH6+mYyaB0Ue4Z6Q4Ih/56hy8/4c9tXTHOJXO OKnbJaA2i4Q4m0EjbRkHPNSYiNF8n9yAEZAY85VmJTSNTHIWmtxahkQSaD7XypzM+XMN SPEg== X-Forwarded-Encrypted: i=1; AHgh+RqZ1obI79q59V42U4CHKW6EcVe/ntpFf9+AoPH38ZJzVLcHAIoIaviPOvrYXTZG9sFO2IZ7XMbecPJumZpt@lists.postgresql.org X-Gm-Message-State: AOJu0YyvGeoCmVNqvwZGzxhctSYorRTFsODFXkJWFdli8Cf64fRrEyWv peSZQESYzDeWNNSTp1vZtFRk4+5hsEyUpxPvKVA6s4ItmGt2i3C8XXGFgVSw1H1JCGcKtxyJvWv C928yO1J/cHxPrzCthofnjX/TTaIniXk= X-Gm-Gg: AfdE7clOldsQTTgJt1Al+pjorR+T5i5fCqjsVuySTIaokPDOYIkgH6hpR2IfhHvXi3/ ntPidNQAaHPLisihIy8SHYrfpEuqFefdadgl3mqzql+fuJZv5vXCrZhFhnAwPi1phMz+ot4m1eZ tasp50/SLVr0SQvEinATKc3cXpEhPYkQeF8pLulidZ4obIJat6lRRT4/QDxqrfNrk+5/XjopMtF hhZSA0/dwCi6B/kQdQtsqcwkQa9tOcZx2rinBSdHn+OOeNi1cdaQG4zLNe0CIpNSwjwdZhH0ow= X-Received: by 2002:a53:ac90:0:b0:651:e1e7:7f50 with SMTP id 956f58d0204a3-66487c71b5bmr5145733d50.29.1782465958495; Fri, 26 Jun 2026 02:25:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Fri, 26 Jun 2026 14:55:46 +0530 X-Gm-Features: AVVi8Cc_fG28ejnmK2TGiHIxdQHYSlnbfh1UB6F1RZbgsGMadgxWqLws-OAvIEg Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: Dilip Kumar , Nisha Moond , shveta malik , 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, 26 Jun 2026 at 12:44, Amit Kapila wrote: > > On Fri, Jun 26, 2026 at 11:25=E2=80=AFAM vignesh C = wrote: > > > > On Thu, 25 Jun 2026 at 19:15, Dilip Kumar wrote= : > > > > > > PFA, updated version of the patch, fixes all the comments of V57 > > > > Currently, I have a use case where I would like to clean up conflict > > log records using a 'MERGE' statement. > > > > Consider a system that has accumulated conflict records over several > > days or weeks. Some of those conflicts have already been resolved, and > > in the meantime, a number of tables have been removed from the > > publication, dropped on the subscriber, or are otherwise no longer > > part of logical replication. However, the corresponding conflict log > > records remain in the conflict log table. > > > > One way to clean up such stale entries is to compare the 'relid' > > stored in the conflict log table with 'pg_class' and delete rows whose > > relations no longer exist. For example: > > MERGE INTO pg_conflict.pg_conflict_log_16404 AS cl > > USING pg_class AS c > > ON (cl.relid =3D c.oid) > > WHEN NOT MATCHED BY SOURCE THEN > > DELETE; > > However, this fails with: > > ERROR: cannot modify or insert data into conflict log table > > "pg_conflict_log_16404" > > DETAIL: Conflict log tables are system-managed and only support > > cleanup using DELETE or TRUNCATE. > > > > Although this 'MERGE' only performs a 'DELETE', it is still rejected. > > > > Is this restriction intentional? I can understand if supporting > > 'MERGE' is considered out of scope for this patch, but I wanted to > > check whether rejecting a delete-only 'MERGE' is an intentional design > > decision. If so, perhaps support for this use case could be considered > > in a future version. > > > > Yes, in future versions, we may want to consider such cases. BTW, > can't we achieve this simply via DELETE? Yes, this particular example can be achieved using 'DELETE ... WHERE NOT EXISTS': DELETE FROM pg_conflict.pg_conflict_log_16404 cl WHERE NOT EXISTS ( SELECT 1 FROM pg_class c WHERE c.oid =3D cl.relid ); My question was mainly whether rejecting a delete-only 'MERGE' is an intentional design decision. Although users can always rewrite such statements using 'DELETE', those who are accustomed to using 'MERGE' for cleanup operations would have to fall back to 'DELETE', even when the 'MERGE' can only perform a 'DELETE'. I just wanted to understand whether this restriction is intentional or simply a consequence of rejecting all 'MERGE' operations. Regards, Vignesh