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 1vfdmI-003fmR-1I for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 12:45:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfdmH-004l1f-0i for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 12:45:41 +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 1vfdmG-004l1Q-2J for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 12:45:41 +0000 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfdmE-000Cau-0z for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 12:45:40 +0000 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-382fb2bb83dso39198061fa.1 for ; Tue, 13 Jan 2026 04:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768308336; x=1768913136; 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=w/siuYZkFVm5d3s8hpE9UqILJZEcwEPwr6AXZcI6kig=; b=WVOGYEpIa+gpUFwjjNeXsjp8nhzzHTbzbnP3bzbT1YfKsMd4tnZMawbHlgqBj0jqJn BKjKjt5ejH9B7clm+Sw//belaQVV4iLV6efTcVubhUWTKMnYLS951tsN/BG3Qn6FYLkq nATfaSFjuOo0FVtK1gJw5kDgbqukE11n574EossRE7IHp4Zr1ttiDsyD3Gv13Xq1Hl+N tztck/eyq4PwX7saYAfn5wW/F9oL5iNM+AYR9ACz5u/OXjsgJWOM9E/xiGLbndYrV2wo u3dVKQaHJ8m0ElmXv7PIQRj8PgiH/ecxC/ExkwL514LobYbJB2KD0RXSnfnhuPUFBn0g nOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768308336; x=1768913136; 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=w/siuYZkFVm5d3s8hpE9UqILJZEcwEPwr6AXZcI6kig=; b=Y0cACdcIMN/g8lx0aB8Rf3PNDL1zvZ4+jEwOasMF9BUYyj14wE1PiYzSLjkCCT1/UA w+sTM6kK8DnH10mSgZ9bwuHAEbEV6u0bOc8bjMMVpE0PJSvlts4p1tzY2szXzJqjmmde QtrswBQHJvjG3fAY7nuNACLL35USFpiZYsgx3GI4uqTFoc+HUZ3dvWf1WWOeS3ZLfk3C EjKFDzYyvHylk89wZ9ZrP0osPWl167sescSCULNZquH1Ps8+2+thxtSmUjr6MZAmF8dl IWZqRR6lBu18BT00B03izQI9EgyiAVxdaNtxITPUwu8GAycj6asm3eoQM6B//Hu61XjL MJIQ== X-Forwarded-Encrypted: i=1; AJvYcCW8um4rEDWZ7kfg4VkDpTnX5u317iwhET6QiRIl4yrVqW2HeJznQn/Mt9zY70OEG8J7IVaRpKQFMLwFBeX2@lists.postgresql.org X-Gm-Message-State: AOJu0Yz5iAU90SplSmAqfb2e6V4mmGJc14E+37spVfltpJKp0Q6p7WJb ALNCkucTYaeBCgwtPMPqQJz1jgLvu02z12S4c8U9gBt+VGC62Ks4SuD9SOJLF9141raUQ0WcFHx 1i0lz2xYQovWcqDmehfr7PmLjMzrJo90= X-Gm-Gg: AY/fxX48FTjiM3cUjSQUH/WUBeCIaKKirD82kCOnGXbWkdcTKIGeYi+mbjTyfjdyBsu fyeNIIJDkzlPjAjpzdQVwIE2IMunBCjalE3kPRSQejev5BFhNaanT13ln7XapJiUu0Tv5xaMmkk +vCzVgiMDx+LUdkG1wSMbi624d2Ps4WwuSnAjienFVcvT1FSi3+NsUkpblEkJYKMKyLjTn8w+zO u0ip7GApTHV4EbVeB6+mXZG4Nkt8DgfbJifeRGdTfX1uWLusl+EUVJyA4JALwN+020scVriLbUT xenrnw== X-Google-Smtp-Source: AGHT+IGIPKxr6QBzROVvlXr9xSKAOv0NWucJOzAXYaqNA+d8K8KCmcsQDKghTH/cjdf6+5mPyuFEwwN8U7WndxRsbxg= X-Received: by 2002:a05:6512:3d0f:b0:59b:8264:ba51 with SMTP id 2adb3069b0e04-59b8264bb8bmr4457152e87.49.1768308335497; Tue, 13 Jan 2026 04:45:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Tue, 13 Jan 2026 18:15:17 +0530 X-Gm-Features: AZwV_QgabCWAKDICWSO28p6l5BHk5KLUSj6V6nV_YNN2_v5YMYM6SFXkIgpaH9o Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: Peter Smith , vignesh C , Amit Kapila , 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 Tue, Jan 13, 2026 at 5:02=E2=80=AFPM shveta malik wrote: > > On Tue, Jan 13, 2026 at 4:09=E2=80=AFPM Dilip Kumar wrote: > > > > On Tue, Jan 13, 2026 at 3:59=E2=80=AFPM shveta malik wrote: > > > > > > On Sat, Jan 10, 2026 at 6:45=E2=80=AFPM Dilip Kumar wrote: > > > > > > > >> > > > > Here is the updated patch > > > > > > > > > > Thanks, I will review the code. Few concerns while experimenting with= 001 alone: > > > > > > 1) > > > I am able to insert and update rows in pg_conflict.pg_conflict_16394. > > > It should be restricted. > > > > > > 2) > > > I think we need to block 'SELECT for UPDATE' and similar operations o= n > > > CLT. Currently it is allowed on CLT. > > > See this: > > > > > > postgres=3D# SELECT * FROM pg_toast.pg_toast_3466 for UPDATE; > > > ERROR: cannot lock rows in TOAST relation "pg_toast_3466" > > > postgres=3D# SELECT * FROM pg_conflict.pg_conflict_16394 for UPDATE; > > > .... > > > > I sent an analysis on this a few days ago but realized it only went to > > Amit. Resending to the full list: > > > > So the summary is, currently, all INSERT/UPDATE/DELETE operations are > > blocked for TOAST tables for safety. However, I have allowed these > > operations for the pg-conflict table. Unlike TOAST, the system does > > not internally reference conflict data, so user manipulation doesn't > > pose a safety risk to the system. If a user modifies or deletes this > > data, they simply lose their logs without impacting system stability. > > What are your thoughts on this approach? > > > > I don=E2=80=99t see a strong reason for a user to manually perform INSERT= or > UPDATE here. But on rethinking, I also agree that allowing it does no > harm. It simply gives the user flexibility to modify data they =E2=80=9Co= wn=E2=80=9D, > i.e., data that the system does not internally reference. Personally, > I=E2=80=99m okay with leaving it unrestricted, but it will be good to doc= ument > it as a NOTE/CAUTION, stating that these DML operations are allowed > and it is the user=E2=80=99s responsibility to manage any changes they ma= ke > manually. To clarify, I=E2=80=99m allowing INSERT and UPDATE alongside DELETE not because I anticipate a specific use case, but to avoid adding unnecessary code complexity. Since restricting these operations isn't a safety requirement, I felt it was better to keep the implementation simple rather than adding extra checks that don't provide real value. So let's get consensus on this decision and then we can change accordingly. > > > > >> I Wrote > > > I have been exploring the enforcement of these restrictions. > > > Currently, DML is validated via CheckValidResultRel(). If we do not > > > explicitly check for the conflict log table in that function, DML > > > operations, including DELETE, will be permitted. While I am not overl= y > > > concerned about users attempting manual INSERT or UPDATE operations. > > > > > Now for TRUNCATE, the truncate_check_rel() currently relies on > > > IsSystemClass() to restrict truncations. Since the conflict namespace > > > is included in IsSystemClass() to prevent unauthorized DDL, TRUNCATE > > > is blocked by default. We could allow it by adding an exception in > > > truncate_check_rel() (e.g., IsSystemClass() && > > > !IsConflictNamespace()), but I am unsure if this is necessary. Do we > > > really need to permit TRUNCATE, or is allowing DELETE sufficient for > > > user-driven cleanup? > > > > I am okay if we allow DELETE alone. Thanks for your opinion. > > > > > > > > > 3) > > > We currently skip ANALYZE on TOAST tables, but I=E2=80=99m not sure w= hether > > > the same restriction should apply to CLT. Since users are expected to > > > query CLT frequently, collecting statistics could be beneficial. Even > > > though there are currently no indexes or other structures to enable > > > more optimal plans, having statistics should not harm. Thoughts? > > > > > > postgres=3D# analyze pg_toast.pg_toast_16399; > > > WARNING: skipping "pg_toast_16399" --- cannot analyze non-tables or > > > special system tables > > > > > > postgres=3D# analyze pg_conflict.pg_conflict_16394; > > > ANALYZE > > > > I think its good to ANALYZE CLT data because user logically never need > > to query the toast data, but they would have to query the conflict > > data. > > Right. Do you think we shall allow index creation as well on this > table? It may help if the table is huge. As an example, a user can > create an index on relid to query it faster. Currently it is not > allowed. That=E2=80=99s an interesting point. I initially considered creating intern= al indexes to simplify management and avoid requiring users to have DDL permissions on the pg_conflict schema. However, I realized that predefined indexes might be too restrictive for diverse search requirements. Perhaps we should omit indexes from the initial version? We can then decide whether to add predefined indexes or allow external ones based on actual usage patterns and feedback. Thoughts? --=20 Regards, Dilip Kumar Google