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 1wd3pk-003rF0-02 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 10:30:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wd3ph-00AOhr-19 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2026 10:30:49 +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 1wd3pg-00AOhZ-2O for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 10:30:49 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wd3pe-00000000K3z-1dTw for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2026 10:30:47 +0000 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-845b733e82cso439112b3a.2 for ; Fri, 26 Jun 2026 03:30:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782469845; cv=none; d=google.com; s=arc-20260327; b=kMjbJgF4tCSO83z/zj4G/a+zvgeEykZtSsxJeAIxC5NGd/pclvRkDGVTroQHvCNoWl xqb1WcjBYw5R8tCNOnr07jRVCT2ReRxYuNW4iFjsUb7V1X3p/4i5gVQRo7fiIzO9zg+l QMGShLrAfmHbsJQ5/ILBy1fEZLKeLZS0BREdujW8pcxD7A1cnLwwRkQieYtVZldWKkIC oHABCvPgincpiB83xz1BPdriD8xIB48Ihwy7Xn9j+GczLYeW98vIjwVx1Cmi6IiU5cM0 bDflWlAwgbZ5pNusV6708aA6yQ5Z5+kp3hGIHaVT/c2gGO6o9T1h892ZnHbiW8pxS7F+ Hjeg== 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=qLIDYr8Bj+ebMn9dyOV9ZbjZVdjZiLSsGn4PoImTdcc=; fh=nHUphD5xk+NhzDzRHnfV2vZ4RQlRiLggw8YgCzRfEEA=; b=I/oyV2tRBXOXwYIfDg2xMT0eZXYxV0ZX+yKs63pzs2WJw7eqZ0yLCT3QEjnviEu18r tZJpcBlfQnUe7s730clCZ5QNgJ2XF88VLsaaINDH/gyVhUFFRdMX1X6/HEaGpQQcgLo4 ADeoYjzpRRoNmbtlJL4wgonp92zpjxhX86vf4REMVzxHMSuZSNw9Fka5eRCqoz76eNQc Ns6xw4lTAX10AzxEZ/QHhXNLgxLVDLJ+kv5DyicVWwbBuSiKqY5XdPLXMLjSl4MYD6TI 21VUkJh3f1Ik3kdeM3tug3rZEB7bYelIwZBUP5Gd+hoE1ulCnWZFsxUniin9tv1Euhak osPQ==; 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=1782469845; x=1783074645; 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=qLIDYr8Bj+ebMn9dyOV9ZbjZVdjZiLSsGn4PoImTdcc=; b=CukJGBj4wKIIqK+3qEG/Cp+xJOtG1jL+NV9LBTdVWU7FkMz2sttbExWf5+stQIuTEm 7lyPIDk5xGpUHHNrt6TIpM7+gI+WFrM9miSmf1A6pSW3z4MiNmrzZi4JAi5GNG3/Jwsd xEi050zJAukjwDeceLq4j0/b5vnIzbKigX1kqcLXIWTTpHnEM3qEX2OS6yfuqF5K9Ig8 1h7o82BXOXZGt7TmImoi+rldaTyRoB0lihgwAU5d2ESIdGSLvv+5RSPi11kJeHObhx4l fx7m5OIM8rqScYmOggZ/ly9mT8IxaeVWWsqPJ0hHHthfb76SRElGHz3rMgDR9pVCwrVV 0XQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782469845; x=1783074645; 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=qLIDYr8Bj+ebMn9dyOV9ZbjZVdjZiLSsGn4PoImTdcc=; b=MVD2+dASjEj44yhhkwzfg/O+5eg7u1HPFSct5GlRYTU+dmGM8yvK1bNCgt9d55Ep5u KzLzVFWmKwFA7VJ5k/SrKe/rBI5i4Q7Ga4TO2QsDQf2NNfPK/TT/WNQv6JPafNWZqD0I 3hb8y4TDqRRNVzRl06QPNWYsUefMR4Lh+NctxeEhdPmLmxORD6XQSM2PqND/gqYShlfY O0B7gnTO1XcPCO4GrBD+i0wTxllwgsw9IjWokcDwl/gb+xGuhWfOY4hNdPnwjJPOOBBu i8/NSjV8ffx+002cYVqnlfqmC5XSRqt4vpXj/IvwZ10cqLoffH5MaJ6oSsq9XP9vXGGA iffQ== X-Forwarded-Encrypted: i=1; AFNElJ/zMnokOqqSxFl0GL1kDaV6m6RUViko4DW4c8SkjJh/BUVbT33+E5/V1ARioc+oc3GrCo0F9tYQ8ye1X23U@lists.postgresql.org X-Gm-Message-State: AOJu0Yx2hAtL1uAL57KaL43MWHsM45dgdd60TV9d1E1PiJ+X/ruB47vm 00T8KVP3aKFTKwZMT7OSXFczemqzVDvdWR4Zdco1AfwzoPm4C48Bap7rKaTuAgCjRSQD7q52gAD YEJeqA8ZJv00nPozsK0RtEwv5A61HLXc= X-Gm-Gg: AfdE7ckC+dvwMGHhNORPOlc8aH5t7YMLQZLUgMhF80vUwah6Ng11wY4DUl0/givcPH1 HhMWii0wrDxCOB7KC7iarKVlV5rJlXpwnWULhLsd+mgyHHRWL4lefjgNC1jZOd0qXhWkA+9LeDi sHSFfAl13mPiVvuL9L6uqEcJG57s6MU3GRXAGffzzXbc7/WReABUYQiB5ozix0Xh6dA6h0sbvVs Q/soCNkyn8JIaWsNCB3dlNTi18rm+DPsGZn5h1vIsJGEDd/BwTHyZXpgcWygfrNWR5+7+YlWtVC 0te5RYKk8ZfOuA+pZGRD5m3rJg1elhQ5zGriCI6P5/elVFj5MR1/4J1Fx6Nha1j/U8Z/ometuA= = X-Received: by 2002:a05:6a00:338f:b0:845:40b5:c4cc with SMTP id d2e1a72fcca58-845b3a2ca9fmr7275203b3a.20.1782469845129; Fri, 26 Jun 2026 03:30:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Fri, 26 Jun 2026 16:00:32 +0530 X-Gm-Features: AVVi8Cc0k2RHiRaLhkqaLHD8wNQ8_tIgqg56rAFr0hhsD5-XqJ3wQ9pCvwD1BWk Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: vignesh C , Amit Kapila , Nisha Moond , 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 Fri, Jun 26, 2026 at 3:13=E2=80=AFPM Dilip Kumar = wrote: > > On Fri, Jun 26, 2026 at 2:55=E2=80=AFPM vignesh C w= rote: > > > > On Fri, 26 Jun 2026 at 12:44, Amit Kapila wro= te: > > > > > > On Fri, Jun 26, 2026 at 11:25=E2=80=AFAM vignesh C wrote: > > > > > > > > On Thu, 25 Jun 2026 at 19:15, Dilip Kumar w= rote: > > > > > > > > > > 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 conflic= t > > > > log records using a 'MERGE' statement. > > > > > > > > Consider a system that has accumulated conflict records over severa= l > > > > 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 lo= g > > > > 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 wh= ose > > > > 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 rejecte= d. > > > > > > > > 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 des= ign > > > > decision. If so, perhaps support for this use case could be conside= red > > > > 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? > I agree. thanks Shveta