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 1vfcds-003TTg-30 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 11:32:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfcds-004UdL-02 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 11:32:56 +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 1vfcdr-004UdB-1V for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 11:32:55 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfcdo-000Bxg-2X for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 11:32:54 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-81ef4b87291so1512517b3a.0 for ; Tue, 13 Jan 2026 03:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768303972; x=1768908772; 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=J1ZLVXMi+eCLTP3eWyxEUNJPwL9Foho7qA1MTa6zYjA=; b=V5yI8Lk4eCJPpZUXoEvpexDTtRsHMj2OUC4DLtvE/w4rY5W3Yq/vqY1DJsHXC33iPl XiNAz40QjjOxrI5dyKiH4tc9cRiOJ38JlzIrN+iLMMgnZDuSmc93Yt2h3iOWoqvMsKd+ 4RRT2XIbb9UNH30yskEcupQnMibsg2D1eKZHgIIFxzk6ZADYTrZF8ug2AlCpKmUUsFVm kmexUUsAcDFyHZpVaYncF/0pl8pb+AYl+xtVtnUxnN7//olVWbKlYsMQTAHT5CSZfQZt E2qy/VeEG0gCFzAQRs3d1ufx0H3tfrqJT0AmOljsb4y2D1tz2reSQRdT1oMHOPvDIEj0 DBIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768303972; x=1768908772; 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=J1ZLVXMi+eCLTP3eWyxEUNJPwL9Foho7qA1MTa6zYjA=; b=fKnirt39K/41SdqwVX0i8+J2CIGrpaitH9zb9YAsvpA9OjbQD5n+XE8slFNxSlt+0n vX0nGtm/yCoMeyQgHvmvXOYFYn5DABTgmakdqd2RAQVth6gIWB8Ts9cmmN31Gl8JofZ5 jv6jnsaGDD4YGO9ofzFCJZrfj+JzAvr/5HbjE9JIr+lgFKLkJhnKrl8rFM5eMWMa/mME X/OZ24niGeM6gfMBrvt9i19Tj0i8AbaRRVfoKhlEz0ATkmkn4gwV6geHCOyfiD7y2GUx Yl2UCAAdXNfXDD3K28eTxa3CmDbFWL08JOv6GWM3AcbIPAgWsegXXx4PryQe+Dc+UXHQ AP3A== X-Forwarded-Encrypted: i=1; AJvYcCVLrfjbXGfe8ibTxb13ALO47eurtmACHcId6tLAXxtANVX6ROFfoFdLOq8x7dI3HErSm1L+VsG/MzrVMaI7@lists.postgresql.org X-Gm-Message-State: AOJu0YwmVSTw2UQBa+FDJd97DI2MvVHUMeZHsz0qRNEcQMZqvuDpDWsv ZBluGp+ZRymHbo0+tOot6JQUYjuy+zKaAPx7Wi8IpvYVUgMA+6TlwxtChFdk/O6+1KwZbHVT3gg gxVO+etn+kPOlryEzesVMUjP5pCL7SDU= X-Gm-Gg: AY/fxX7I/MPDTvD4up078BAk2nLhGibzdZ7SXsOE4lKr7FGIdd5mh75ycTFFBsnrFwb BzmH57LkH1IG4J4a34xH+n9WB5Wa+QoouzxjWfh3T0CCXs/LEcS7qc5j8jstavzZHuZuoJSIxCw v0dZifnfZ6XQdoYRFc8reN9X6uGncb5Szv9SpsFEoByR0Z7etqfnYNVp04sep0kX1PBDDmJ/pCM cLPc98vf7pHmNunaFV4XnCUP0IUIphj9mwCZohDCvjN4u6ESjcnt6aNJdZAHpRa5uxo7dpapbu0 P+OEpJqj61++4rDJQ15M37BftY1xwyjig9GeO3cYv+DS/29uX0c= X-Google-Smtp-Source: AGHT+IGOvmcoVK/bE2OlOlRTkjI3pQec84SWav6SuWdm9Oc2mCQHZ64r/vUw7o1cxGgknlO+EgBEKgKx0rH5jxsz6bg= X-Received: by 2002:a05:6a20:a128:b0:35d:c68e:1b07 with SMTP id adf61e73a8af0-3898f9dd184mr19779045637.54.1768303972369; Tue, 13 Jan 2026 03:32:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 13 Jan 2026 17:02:39 +0530 X-Gm-Features: AZwV_Qg0uPrMXdvc-MXWBW2AJTZrz_o_KHEuM30X_kKFRihuCMmgX9sTq2OWUVc Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Peter Smith , vignesh C , Amit Kapila , 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 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 0= 01 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 on > > 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 o= r 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=9Cown= =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 docum= ent 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 make manually. > > >> 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 overly > > 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. > > > > > > 3) > > We currently skip ANALYZE on TOAST tables, but I=E2=80=99m not sure whe= ther > > 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. > > 4) > > It will be good to show 'Conflict Log Table:' in \dRs command. > > Yeah, you raised this point earlier as well, somehow I am missing this > point from the last few versions. I will analyze this and change this > as a first comment in the next version. Okay. thanks Shveta