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 1wd35g-003qiV-1Z for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 09:43:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wd35f-00AFGL-0G for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 09:43:15 +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 1wd35e-00AFEl-1e for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 09:43:14 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wd35c-00000000JjD-2bzc for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 09:43:13 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5aea7bd6e18so354384e87.2 for ; Fri, 26 Jun 2026 02:43:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782466989; cv=none; d=google.com; s=arc-20260327; b=qxiosYk5cVzCRC0zuOMJ6GXf60iF5hPKt+h0Tjck5yf2RvlQ730YNifCEb6aoUFPJh 3Ymf0g1nBg+Jnmn9otAt/bYbTYrN42h70J1a1iJVIPW1ygIIVV8OhmTdJMQr7pqZD3mt My4E95ym7WJLzN5kwY4OVDVVExaZrWYPlZoIOK5TiKEPApqdIUnB6BJkdrS1mtx/XcPk FgMu7DRzACyDVSm1xlAVZ0R0iY1uBS6N7jJC5RmQoZmI3+8u34BH3CJDrjipUvkIyAzR SzdLgENBEZZSydbpz7wtBpJWpGuyJwCjFtOwSdgTB2M+K9xzVSpX8ghlM9ph8Mg47Ja6 oprg== 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=vpQy9zYDABUQ/W/fOGOv3gQ41vt5hNUnA2Zu0VCa1FM=; fh=3WY30ZrMteGmUrtsR7Md+LJKurzlCrxjYiqPLqmZczg=; b=BUPl7C4CEVuyw9p9rbVoaGMeYe1qXxYFaJZCZxMUXBY7xMh5Rc9gLgjIjEnMyki05x mEyp/1GoOv3V6JMp673H9Nx/i8ZhHmjOV9pJp1jMaqep4tQlSWm4DfkgkRwszkBkqBMv +1k3cXmrZuwzm4FFmeGi1vIEXdyA0gsSF7Nzf/cC4U0CXknFBNlOZ/mD9+3o9Gq6YRAE IyvMqe1ldSHmDGSzzfo2gEUWYcg4ezYhw31B4APhW3kgaCPOkcXbOr6OrGOZ0yvvtVJu xGGdRibv8zxxTmyC+PMf9DtFrnqYF3Lx9eeoLdLxHhlenOwjWR/z+SN+U08fmFRlypeN eq8A==; 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=1782466989; x=1783071789; 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=vpQy9zYDABUQ/W/fOGOv3gQ41vt5hNUnA2Zu0VCa1FM=; b=kJTmLdHkweVX3dsyc/oeHxXikqBboGwlEuxFZqGYekgymKsdUa3Q6DAyoRsUF9Mgkz P4/MG4IYwcHSfRGPkx/EbkMg1+l7O8FDdBRc2P6gM+S+gLjlCkCjEui9zGkSiohVILIH NobNdjLykVJESWP5oFc6JZhMDjp/QqoDdgN4ar3/Od1U73IiySCKjrJj/dep/OV4+rg6 NW/koTSLL40uucbMN3l4aXAACsjcAu/d4p6GjrQ0/cBw5wLdgzF+wnjWhXBf1081LbMY vBvdZjxDEgb4DgmScsqpwzwChPW09lbsv+WHvghYqfRS6JbTB9loX6AiYuHoSKD1xJ2s idUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782466989; x=1783071789; 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=vpQy9zYDABUQ/W/fOGOv3gQ41vt5hNUnA2Zu0VCa1FM=; b=TzpMHookwD3wTKkoyAn26By3E8ipEk76Z0kJz5VeO5bAIPcUoZbN8hmGdXh6f71KIB EaU8FImDAN9UwxPrarP6xscfKfo+gqymoJDL/XEG+UPe9gHWX6t8V0zeLCm+I6Jg70Jd oP5xc6RvQBch1/8LXTEzANQhIOFul4mhqASlyZtIMbTIoGMkD4bJc97AIudnwAPO5jq+ P2BQFfm/LHjh2agO3mVZq9W/MyJl+w8Z2T2uAArcQc4z/WNy+15bJmcH7eUp5ZsG/Snf h4w06FkLYvdw7/1uTAB7ATDoNrkO12hcPhe17qVrtw9XTj9dHaEjVVxq9p/ulinxcD+0 S3Ow== X-Forwarded-Encrypted: i=1; AHgh+RrTIrHiPWiWvjHliPiI23L5BAfkfB/2/sQ+qst90CpyA7QvVN1lsJvjGjSlUZ4mXqoZkClZaGlbewuK6mx3@lists.postgresql.org X-Gm-Message-State: AOJu0YwhXXL1P6KoqEyR5K+gKUIaKiubbk5/eqyI0RN/nOAXe/ddFUXu O87aTlNha/4NeBdXVQ4BYsqOM0G4k61fa/gE43ZoSwknenTpVgIZKGQTeOVLFhaxU23mcxD/xGl noDkNuin3N0rXdTs9K+RhHQBQIN32A+I= X-Gm-Gg: AfdE7cnlmZNddTchFOYYzHBvm1TVyPrFFzRCstmM8Hc71fWLTvBtEfX4sGo1NKedR9D LyxsQ1GZBUNgeZWNbo0hWxOAoCMDYMEP/nkBl8ywQdpYKjddBaJi26MZYFTlPbd2BZnG43Za/xE h7JFS7qT1mcY17jlxE3L0b1yHLONkllGns37vm8HXoeXkXB6xmuWIT+hDheVO0dvk0Dyt3AblzH JO30NnXAT0SRdUkvIptwU6ZAaMIBf8yLDiqziiE1rxhwyb602mKkRFO6szfnwLhd4eQHQrBXrD8 I5fePsA0g4WFjHzV9bQnvwLzmfsRKQ== X-Received: by 2002:a05:6512:8041:b0:5aa:6931:cced with SMTP id 2adb3069b0e04-5aea1f64842mr1558562e87.39.1782466989080; Fri, 26 Jun 2026 02:43:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 26 Jun 2026 15:12:52 +0530 X-Gm-Features: AVVi8CdMDdZm3qIDMBL8opxdBmnf1lhcYV301Eg2DkXBlzXBcipywIlJd2l0enc Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Amit Kapila , 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 2:55=E2=80=AFPM vignesh C wro= te: > > 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 wro= te: > > > > > > > > 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, an= d > > > 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 whos= e > > > 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 desig= n > > > decision. If so, perhaps support for this use case could be considere= d > > > 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. We should focus strictly on core use cases for the Conflict Log Table (CLT). Users simply need to view conflicts via SELECT, clear old records using DELETE, and wipe the table using TRUNCATE to prevent storage bloat. No other table-level features are necessary. At this point, I don't think we need to enable features for all use cases, such as MERGE. At this point, we should prioritize a robust table schema design to ensure long-term stability and compatibility across future versions. Since these tables will not be heavily utilized in the initial release, we do not need to support exhaustive functionality immediately; we can easily expose additional operations later as demand arises. Thoughts? --=20 Regards, Dilip Kumar Google