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 1wVQyc-001xWZ-1R for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 09:36:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVQya-00BTj7-3B for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 09:36:28 +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 1wVQya-00BTiz-1S for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 09:36:28 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wVQyY-00000001DQ3-2hP4 for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 09:36:27 +0000 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-2bf114b0cf9so14022545ad.2 for ; Fri, 05 Jun 2026 02:36:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780652186; cv=none; d=google.com; s=arc-20240605; b=cwnxD8BWXIswVr2r1i4z/47cN3NUyDRe0UeIAoMhmqGmhmN+4WL7baGULIM+5yBen8 IaU+4P7EolRteL/g9R8V4dA+75m3O8s1Li9z+wKLKU2+RJU8CU05nP88Ecd7KnOlMjc1 6/hwkT3obIADtTSCBF/EjZ5sTMSH+2K/2CTuC/XzpE32DZzzzS0Wn7E1HsHGZDhwmCdn jeJYQkvrQwh1jIgToAyiGN/L+o5EUTWpi0mxuAbPUyaG0SB4t9+whEh/jWTp2eCj206v 07r6AS0wLqM/5p6gDKMM2KEZfVnb/A0ur3JuYVIuMmy8XBROThCnT5xE3VMT1R+uA42W EpKQ== 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=BpzY4wwjB9TnWL7mDU00utxxWgRYDoamcoQLvyZddag=; fh=oEtJvgKv7ybNZ4lvWTdpJkf3hyvqnTMWji/VEq5Lu9Y=; b=YMhsg/8J2FBjk92jOwLmZFGDnlKpJdoOUVNr03QFLDIpXy64oSFXucdiSbrhJNgULM bGZBMi1tIf7uCXc6T6GBhUpYxrm12cTaP7qLRFrM/UvOOAUiueHx4V54il/AZVZkk6MW PX8O8vre7miWtRIZTKKg9+E0RGZ8EfprIFQQyv7x1tBaNF6sYWjnA1r2vUDV52cLlqVs 7lvPh+xbBp1+YVXt4kFTAj52d5vV118biW7QWJq6dvj0bmz9qkMjVe+eIWHz1CkNvU5G wUrOn2zZ05ulrAW1kN6G6Ld5zjBfDs4ahSxsO+b2RyRL9bVe72Stf0QlHUy6tsn3JYyN GamA==; 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=1780652186; x=1781256986; 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=BpzY4wwjB9TnWL7mDU00utxxWgRYDoamcoQLvyZddag=; b=J/Ov+vFpKYjqyenOO/SBK6hnsBJEWEEgOxW2ZuXMBPhB9qUGRW7OMZ7ximxRLj4/O6 hayFiuprTxwTei7Wt2b1ZewLNv3KkseOE44XCoOU5BUVtw5pzQiOJQjnCk2fkcuw9jHH Sv7CRERKtZFFTs1aMuVzoA8TCGcstdhSOvPDFqmHlG028gRa6Zif4naGpEX/JHPUiK7f mcUtvYkrv/h/53S9Tbon1MW4+vl+8ZOFKN0YIftgPWY1ES10FLJo8T4v9N24Gwez2QV+ mEKBt3eC3Ax0n8PzMig1dcqEgbz17eEK1XT9xSKmsbdXR/bWQva9zSsMXau3JLq5aLWb c/zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780652186; x=1781256986; 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=BpzY4wwjB9TnWL7mDU00utxxWgRYDoamcoQLvyZddag=; b=YnOfHWbHSSfuk3eHeuM+HOjIY9T8+2d53nWwzNKQRuueX9ky8t7FdICVP/S6OHWr0q Z0tfe/2TjK7h5Yk2nCc4/Wnk2ZoHR8Q3wqo9hUy3O98+scRdYTJ9uHNd0TobSBMcQiBR magEDB/iTnuvY/lNJ0EFPRmlxQ9zDOTrYRjvtPe4dNBRtw51eJVn1wEW7ELzis8RPQlt DrDtZngHKl9y5QTQYtNdxA74HpDOwn6eItAZ/jrIdAFetb/8Z6CX7hcq0IJh3xyS6smE BEv4wuIi6zGvv/errUFo3Twl/6SGEiZvKxn5QVwfuhGmAdSAr4EDoYDsn7D07Irs6Zma +6bA== X-Forwarded-Encrypted: i=1; AFNElJ/46TJ52gIay0XjNX83AjjllNNMaOpGKd8VQQcxLjO+kqlSVcL/kJufOZK8nm6v6FyTrdnt7/ZikViYaxM8@lists.postgresql.org X-Gm-Message-State: AOJu0YwpO/pysnIQ8Fi/oSnz7iXmF5HOA5NOHkbZpet4LAiO0XDPvrVs cF6C17KbYgQ55uqO7ga635NpRSpWRfmamt9GjtJuocuC2DjYURtuoy8GHcVtMqn0geGj3SyNjdY OHamXssTUN+quIEB3F27AGwmgW227XQo= X-Gm-Gg: Acq92OGrMnYpvmf2X6rDPm+3dYDKvWa3E2fhE+xWlt2/hJRL8qz1DuPGVqEIj+KCwk3 NmD6C4jhXC2PVcOR5l5bdoW2TodBWE7x7S+qf6Utq2BfJ/ZbpC7ElUaAfjD7CmtpRAHijQuuhPH TxBrXulw0e9tw2dhL9jIDrw7e/VY2qdXl/7JDcRAQdqmS1YiQx8TDSwuIc8KjqmeJJbmEeE6zUU GbhwJm0zoR59i0J63JemgQDf6m0ovQXk7hXU7CAeezdvMQQm9B0P4gNJ85idxBr1iBc6vpayPA5 mSHiRRIheUSOa5/8meY0rOIuMMgeOpOa59C5B+vMZkILvvZBGEaI3Oth+hWHXqX2zDcJMtPCqrC 0bFAgR6gV1xtTGKariYn8o3rt5SfqaqI= X-Received: by 2002:a17:903:120e:b0:2c1:f29a:b554 with SMTP id d9443c01a7336-2c1f29ab5dcmr13465395ad.21.1780652185684; Fri, 05 Jun 2026 02:36:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Fri, 5 Jun 2026 15:06:13 +0530 X-Gm-Features: AVHnY4LwvL127UlatuW6_S8HLhW4q_dJLIQjfMwnnDi6feGDtOr3EUFoh84B-PM 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 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 locks 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 subscription > > "sub1" has started > > [247433] LOG: process 247433 still waiting for RowExclusiveLock 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 16482 of da= tabase 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 on 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 explicit > > 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-purpose > 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] > @@ -92,6 +93,14 @@ RangeVarCallbackForLockTable(const RangeVar *rv, > Oid relid, Oid oldrelid, > > rv->relname), > > errdetail_relkind_not_supported(relkind)= )); > > > > + /* Disallow explicit LOCK TABLE on conflict log tables */ > + if (IsConflictLogTableNamespace(get_rel_namespace(relid))) > + ereport(ERROR, > + (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg("cannot lock relation \"%s\"", > + rv->relname), > + errdetail("This operation is not > supported for conflict log tables."))); > + > > /* > * Make note if a temporary relation has been accessed in this > * transaction. > @@ -198,6 +207,14 @@ LockViewRecurse_walker(Node *node, > LockViewRecurse_context *context) > relkind !=3D RELKIND_VIEW) > continue; > > > + /* Disallow locking conflict log tables even > via views. */ > + if > (IsConflictLogTableNamespace(get_rel_namespace(relid))) > + ereport(ERROR, > + > (errcode(ERRCODE_WRONG_OBJECT_TYPE), > + errmsg("cannot lock > relation \"%s\"", > + relname), > + errdetail("This > operation is not supported for conflict log tables."))); > + > > > > -- > Regards, > Dilip Kumar > Google