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 1wWnSB-002rTT-0q for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 03:48:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wWnS8-004faW-39 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jun 2026 03:48:36 +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 1wWnS8-004faO-1i for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 03:48:36 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wWnS5-000000025Ga-3cu2 for pgsql-hackers@lists.postgresql.org; Tue, 09 Jun 2026 03:48:35 +0000 Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-36ba285e98bso4981315a91.2 for ; Mon, 08 Jun 2026 20:48:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780976912; cv=none; d=google.com; s=arc-20240605; b=Bln4GVYIwt3YCz5GDN4/ZkicqgAaQW6g9Z3k8tQbnd3F6zOSdou9UHKzp2j8znS8h9 yh75V3K40dGQ9GnWx/Te6IIRWIBNtpeT+g7od/GYUkvOb8TasEFhT9juRn30W7SPu+76 W8Aecmp/qZUcpppRvvTR1cN4xYTaSroiCa9VZ/dFQwqWEzgIf5msPdvCCMYJF3tNiot8 bKF00tlh1OgoSWX/W2VxvrPosbYnLeHIaJw764B+MAYCMYTOT8A2XBEk4Vk3EHmipXun pZ/YOBWfMDJodOBVur74kGjw/JhIQuaCW4hlOD3yqBJtWP8CjfPTr6k1G56aqUFzlwcM 2j2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sVWYFPd11MC+A4cTsLWwovpKtrJfqpcl5y0oD3Dax8A=; fh=3+umEWe62WQBazfr5CNWYHlb+PO/Viv8yCxbwekH1lA=; b=KAFVNyfqPDGXNMnLNM+FoNe6KtqkBgb97sMfCn8Z5tHmr+bmIg5O6Rz8zGG70+923c RFADee0O1trdmdiyVt4KJVJR10QL9tYEyyZl71eg8rwCRr0L8DgveYZengivCoBr5QKS lYnxdQyCU/hZCHv5wfsGjmCE8HAoDzA+vE8mYaOYF62KqTgbFAkqxdYu1wBSwKCmDP4a 34zwp2uSn1B+F9OkEiUU8gL7sGSOASYfv18B+mSPivTeEI/HOcxw7QqYkb0BF4n2qAXs Umfbk1AYjRDURHUWNM5yG2niWcu507NKaKqgu5jeEXoHKKocdbbyl61QK0YvUEZUsE7a wICw==; 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=1780976912; x=1781581712; 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=sVWYFPd11MC+A4cTsLWwovpKtrJfqpcl5y0oD3Dax8A=; b=GdC6S0kc6znoQL4xq1aTxKnWkUawbjgdXabPE80btD6HIKtfg2q3EkBc+ay/k/+kkj OoObaWr1064uzu28h2yS/SiMygI4tuPahSTBztZYIc4PxAR4vgS6/LGonjILvqa4XlHZ URxjiJ9321bvZ/I+OWjMr+cUTN7cpgZgp6Fz4XzHmCEpgjXjRN62qx6qHshkgXvR8AXb Tkok1OtU0EX7iqRx8uJjQiAHcV94zALd1jZPhr8LbxiC9OSGpDjKYWW3U0zZSr4KEf2M 3F+u9F/9pjZ+EaRRC//NMZV8uXMtB1MNWtYlZCBRtYiiQ2pYt+JmOUypY8pmnMea/K1E WZxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780976912; x=1781581712; 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=sVWYFPd11MC+A4cTsLWwovpKtrJfqpcl5y0oD3Dax8A=; b=Rlq8J3HxJRUHuf+PnXUKYvmYR+Za0cBzM+ivuClJMu/YYGRCt6vDTMMLOQTxq+Jn2i XlmjtE4xljIq3IeZ/oZ66TB21mUXQdU9bFQVyvY+GE3o3stM6JDAfOlmxFgNkrF0qxfS hTw7F19q1X/Uk1xcPeCdqFC1xVJlskSokJL6XttsDDjRJf8f+jrsse9cSmS8eU1TSiHa 1PBeg+IkbyRXpv2yduLaBseWUnl3O6YxMEZUXsm1txhAbmt6qItBrYp+CCkqj1e4B21k iUQrVEiDeiD38ZPd4tQxA9DRMsRh1MpBnpGyP4fCndtxf+lg5cLbPcDa+1KRhJEfEJw8 XMrw== X-Forwarded-Encrypted: i=1; AFNElJ+lZrw3N9+r/quyuF/r+LkYJf7HUzupTHEfS4kGDV/hsFvywgMLm95bL+aZqo9XVQ6NpT+TQNsTn1fGl8tC@lists.postgresql.org X-Gm-Message-State: AOJu0YxwanK5+vmcM7QbVcE9McQv5l+N4rGhyA+6+2c0/XrpZtZWjKDO G8MPjdcMmhyvUfWSM9qJkd5V1BotmHH7y0bJTPDPdEYc2cokfD7I+h0xwcKQwxeuKZwyv7oezQO uXGsU4T5xHYxBbcaWlfgQL/2o33Qf73U= X-Gm-Gg: Acq92OGocY8Rfxk/WCGr/m4ej8bPMsJlOs9M87XW2B1KuwuMeoQdDcG4mph033sg5vv TltafDTbPo0sJAzU0UVwtnNsl+4nDhfgYsPy+85Y71LEX08q6Pwwz+JocOhMr9NNlyqzqNkZ/ye B/el4A3uvX1Oop/TPUmT6Z+CXPHDBjxeVaGeGnp5itUjxwAZz0kLgE3QDewCY8NiJ4yAWV9WnFm MnM9ZvdS325epe3SkAfzHEbMhsGc9r5EVeYGoS9SiELniBilOSA/onF/BMkTdr1+SIOqO35ZvUC 28MuOQWbe9s2+rih8DxSPZTikA6PD90EdpC9WQx9gotO/uCsoOoRpzTTdQ2n1A== X-Received: by 2002:a17:90b:4b0f:b0:366:1172:597e with SMTP id 98e67ed59e1d1-370ef2efae9mr19813635a91.9.1780976911571; Mon, 08 Jun 2026 20:48:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 9 Jun 2026 09:18:19 +0530 X-Gm-Features: AVVi8CfuKhL8oZmkn1jsMBTjD8EKfCwKodN_zSyoVnu-kplMajJ3pI-3yEpg0f4 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: vignesh C , Nisha Moond , Amit Kapila , 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 Mon, Jun 8, 2026 at 7:01=E2=80=AFPM Dilip Kumar = wrote: > > On Mon, Jun 8, 2026 at 11:43=E2=80=AFAM shveta malik wrote: > > > > On Fri, Jun 5, 2026 at 4:22=E2=80=AFPM Dilip Kumar wrote: > > > > > > On Fri, Jun 5, 2026 at 3:06=E2=80=AFPM shveta malik wrote: > > > > > > > > On Fri, Jun 5, 2026 at 11:53=E2=80=AFAM Dilip Kumar wrote: > > > > > > > > > > On Thu, Jun 4, 2026 at 4:05=E2=80=AFPM shveta malik wrote: > > > > > > > > > > > > I noticed that it is currently possible to acquire explicit loc= ks on a CLT: > > > > > > > > > > > > --Session locks table and does not commit txn: > > > > > > postgres=3D# BEGIN; > > > > > > LOCK TABLE pg_conflict.pg_conflict_log_16481 IN SHARE MODE; > > > > > > BEGIN > > > > > > LOCK TABLE > > > > > > > > > > > > Doing so can cause the apply worker to block indefinitely when = it > > > > > > attempts to modify the CLT: > > > > > > > > > > > > [247433] LOG: logical replication apply worker for subscriptio= n > > > > > > "sub1" has started > > > > > > [247433] LOG: process 247433 still waiting for RowExclusiveLoc= k on > > > > > > relation 16482 of database 5 after 1001.030 ms > > > > > > [247433] DETAIL: Process holding the lock: 245584. Wait queue:= 247433. > > > > > > [247433] CONTEXT: waiting for RowExclusiveLock on relation 164= 82 of database 5 > > > > > > > > > > > > Toast Table behaviour: > > > > > > postgres=3D*# LOCK TABLE pg_toast.pg_toast_16384 IN SHARE MODE; > > > > > > ERROR: cannot lock relation "pg_toast_16384" > > > > > > DETAIL: This operation is not supported for TOAST tables. > > > > > > > > > > > > Should we consider disallowing explicit LOCK TABLE operations o= n CLTs, > > > > > > similar to how PostgreSQL handles TOAST tables? Or does anyone = see any > > > > > > legitimate use-case (I don't) where we would need to allow expl= icit > > > > > > LOCKs on CLT? > > > > > > > > > > We need to add namespace-based checks here, as the current logic > > > > > relies solely on relkind [1], which classifies TOAST tables > > > > > separately. In my view, choosing to either allow or disallow this > > > > > behavior will not cause significant inconvenience or seem unusual= to > > > > > anyone. Therefore, I prefer the path that minimizes special-purpo= se > > > > > code. Since explicitly disallowing this requires additional > > > > > special-purpose logic (as shown below [1]), allowing it seems to = be > > > > > the cleaner approach. Thoughts? > > > > > > > > Okay, upon analyzing this new logic, I too prefer to allow it. > > > > > > > > I was thinking if there is a way to set lock_timeout in > > > > ProcessPendingConflictLogTuple() or try to acquire lock and if it > > > > fails we hit 'ERRCODE_LOCK_NOT_AVAILABLE', log a different warning = in > > > > the log file and let the apply worker proceed. > > > > > > > > But if this too is complicated, I am fine with the current > > > > implementation. Since LOCK TABLE is a well-known command, if a user > > > > explicitly locks a CLT, they should be responsible for the > > > > consequences such as blocking the apply worker. > > > > > > +1 > > > > > > Here is the updated patch which fixes all open issues except Peter > > > reported on 0004 patch, Vignesh would you take care of that? > > > > > > > Thank You Dilip. > > > > v46-001: > > > > 1) > > > > +static bool alter_sub_conflictlogdestination(Subscription *sub, > > + ConflictLogDest oldlogdest, > > + ConflictLogDest newlogdest, > > + Oid *conflicttablerelid); > > > > +static void drop_sub_conflict_log_table(Oid subid, char *subname, > > + > > > > Can we name alter_sub_conflictlogdestination to > > alter_sub_conflict_log_dest? Feel free to ignore if you find current > > name better. > > Yeah we may change that. > > > 2) > > Ran all the tests again on 0001 alone, inheritance is still working. > > Let me know if we decided to retain it. IMO, it is better to block it > > for the reasons stated earlier. The changes can be made in > > MergeAttributes and ATExecAddInherit; we already have similar relation > > based restrictions there, one more can be added for CLT. > > > > ~~ > > > > No major issue in 0001, it seems be in good shape. Will do one more > > round of reveiw and testing on next version though. > > After rethinking my previous stance on blocking these operations, let > me clarify the core principle I think we should follow for CLTs. I am > completely open to feedback on this approach: > > 1. Block Direct Mutations: We should block any operation that directly > modifies the CLT or its underlying data (e.g., DROP TABLE, ALTER > TABLE, INSERT, UPDATE), which impact the operation on CLT or update > the CLT data. > 2. Don't block Indirect/Edge-Case Operations: We should not write > custom code just to block edge cases that don't directly modify CLT > data or impact the operations on CLT. For example, if a user decides > to inherit from a CLT, that constitutes unexpected usage. We already > document (or can document) that dropping a subscription internally > drops the associated CLT. If a user inherits from it anyway and their > child tables are impacted when the subscription is dropped, that is > expected behavior and their usage issue. Fair enough. I'm okay with this approach, provided we document it clearly, perhaps as a CAUTION: users must be aware that DROP SUBSCRIPTION cascades the drop to the CLT and all its dependent objects, including any user-created inherited tables, view etc thanks Shveta