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 1wd0lN-003ovV-0W for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 07:14:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wd0lL-009kVB-35 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 07:14:07 +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 1wd0lL-009kV3-1y for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 07:14:07 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wd0lJ-00000000K8o-1CRy for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 07:14:07 +0000 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-c88e3e82d81so265784a12.2 for ; Fri, 26 Jun 2026 00:14:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782458043; cv=none; d=google.com; s=arc-20260327; b=qqtOv62x2ZxquByU3PHR02+8JxQrkSFvvbMo1DwFZbGeetVAXW2AnXp38wK05W/aZL mMD4dqT/3js+OAAW9hcysU5Bp06PKI1hUOVvy5UoEVck+i/iQp6YliwDs5MYZFlpwObK nuEcuYPJwXmOlS9BDmS2lEqVEQZrwfYrpw0sme2QfIxLXy4ztCGVP3NyccGaQGAreo1h IGOMDH/8A8t9tVIUumBlzfoVbFsMtROkca/lY7OJg1ya0xWx5LD+w4/km34RVxEXXBL2 vKkTssLSWDOVuBPrPsOJLuCQQ8NL5RoJF6+ofbPvNaZeHtLkgXdTOyd6YnP6AmTRNMxZ cG8Q== 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=Rn4s6LJbDJjI2sOz4wxmEOrKJIoVzYM235YINlUv3uk=; fh=QTEj6UucZaRd/HO/x/DvReMe0hAdJNw5t9eNNlgSZkw=; b=TJWUeAxFmRmrzFDCyk/H1aE0GfAaURbASAXS5EV6ChhYLdMspp8Dbqml4h49hhLmT5 w4P9gvYt7Os1P0YgMJKUD2RQZ4Ix0Zp1+ssF4av/zPHOg77uA8Z3EwK/uyceNP8R8j9U 6Ia3EG5HWh0fAFP+7kqjbmXaVDCaIDJQT1DjEeuwYJicFdkSQZwxqaZQKHLSNS72mubS MrF5HxtwNdFOO/ZEpTsFZz5vwF/I1HMRvVMXzmhBzF1gRD+/b/b3nwwpBJvCZSF5Cym/ G6OIk/JpztWGjIWffO+f6RhIKrByRopl6miBbPAJ8rqlG0zkqlNa+xtm+43llkTmUd/h z7Pg==; 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=1782458043; x=1783062843; 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=Rn4s6LJbDJjI2sOz4wxmEOrKJIoVzYM235YINlUv3uk=; b=ggV2/QJkKxynUuZ1cIZ5bcTXT6vEXqFDDilGRY4C9iE8jx48wcwpLPkr0pf/m2Zk3b T4qxs//iF7acrq4Owmx1vpECm96y8oeSwQmDpmQnalCY/bxAMbKBheC7oJEIwF8hHxAD 0uiR3+vlj/LlPxjUyprjJ0UY6r2qsQU2l2pQzJsFRigsvAmcplQ6poRSOJyr9m3K21fC z7cOGexlzKxx+R2W1n8+8PRPoGWBtTpdwpe3a0QQmzjtJmmHKqWeGhrDZDcA1VNibpDW c1xZX3zZ8iFkFDeAO5A7KwaGLXzSC7+mLQtSfOY0A+iSs4joBu6UIcROMKG9tK+68m3C vc8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782458043; x=1783062843; 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=Rn4s6LJbDJjI2sOz4wxmEOrKJIoVzYM235YINlUv3uk=; b=WjxEdgGp/Nqo/avTrtN+ZFAetCXjPxPK4UfEhjHv7Hwg3Uk00kfGibZ453UKuxLqE1 tHAXlXaxzsoMdH4DXDNGONPVI9JAj3cEtt10isrW+h56XI9MBXpeV77OVk7dmoMuwGcO IxHoEgqEF8Tt+wVBraLtfYdfJND7QdbCZADJsnyMTDTpkBYVtKa0LkVisNb7eKpH8sUi qMqsOE9/+f6892h9/NpOEnwG4pd4g5KixP+uy4FMGjVjHIyIFKwSY1XuJ3nurZh9iz5+ 5G1DRhnXfGzQV2Gb/CJavSS4HAjvrrr6TeRkOQHn2UjBa7GGmgViJtpgIlg/uyu9t5mG CwMA== X-Forwarded-Encrypted: i=1; AFNElJ8XVRlAPj2cs5zb2XeiHrV6UV59KqyOBQKEQxH7iscVyRIvWLuFMzxRjLdMNnylY4RYLfNdJZ5dF/PKFYb0@lists.postgresql.org X-Gm-Message-State: AOJu0Yyq8DRMP/EHnkw0qN2WXUCiF11kLYsPkL+prhQvGolNpd8SGRFL tTcBVjmAVk/s/x/iZufIJqn382J2opAdIvnZvxEAoTSeH16jgpT9EaY4V5pxnhZ201ThwPPk7Q/ G/DqB93HHOwai58lFJ3GXMQJwltFSzbQ= X-Gm-Gg: AfdE7cmKBvdInC39gCSxajC47zRyx3psMe4VixGtxxAlmfSHDi36HcsRwPQm18EVRPP ZTwBPU5pVE+m7ahPersHJrqYEKYsT6bOhjQjCN8w2xa6tsrG0Ye21eyub0AWXMeSS6nWVuoQLjA ZTSCe2jakzeBSOVZUCpHOgO/rOgST3FVKXdBw3ULqkU2/d/Puis4O1WwG1zDVT06nQ9zlF9ijbF zw8GaOoJumai+HLcCHfYLyavK7mBOA2fxNGb3AGBOB6TY/cQe1zJDrLHup6dCuDswZYvsCUeolV C2UO82WohRfpLulAJAYrG/zxpDZX/XwRsGMCK6+ZpDQ6q0jK9JCoBcGViiggiIt6zoyXgShak1f 6sun7TOyHCA9A7aV39vNLEfSfO//7sRI= X-Received: by 2002:a05:6300:49a:b0:3bf:66b3:7b2c with SMTP id adf61e73a8af0-3bf66b37da8mr45949637.43.1782458043180; Fri, 26 Jun 2026 00:14:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Fri, 26 Jun 2026 12:43:50 +0530 X-Gm-Features: AVVi8CcBpctQNxLoOxWTFUcsPMnXvHUaFvfV-JeKi9xLNUVoS1u4MK_uY6rNj3s Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C 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, Jun 26, 2026 at 11:25=E2=80=AFAM vignesh C wr= ote: > > 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? --=20 With Regards, Amit Kapila.