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 1wVNyH-001vGZ-0n for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 06:23: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 1wVNyF-00ASEj-28 for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 06:23:55 +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 1wVNyF-00ASEa-0N for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 06:23:55 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wVNyD-00000001BwT-0rlr for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 06:23:54 +0000 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5aa4bb157c6so1485710e87.3 for ; Thu, 04 Jun 2026 23:23:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780640632; cv=none; d=google.com; s=arc-20240605; b=NL82WEbxCGGQPPd+tB31zJpq0AZPX9lpnlN7iaIFZdp7mL3kxjQDLL5JH0pz1HKnRv ZOOflN4uyRE1ym54iV6oLdNIOuhd5dn5HZ/eOqruFMqYI+RI/2ZC5YxmhfYMqQcofq64 44MOOVtRFKD1/4DzeAloE0IwtILUttJiGMzyq54NABlpwqcgDT8hBhC8VHkeVuCr6MWX SpFBNAw+JHMRydcEjxp/e+P8QYKlRCg/8BMpr3fuzXMlsBzY5R7vyTgxjl6RVOXB/a1b mwmUf0Peu7/xOW6MNs4rcS9NNvh6uNuoX8I9/EzHAya9ivpw+xkbSi9SHNiergSOXLNL /o0Q== 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=S5ptTmLxALvEKlrM8rvgH3TzuV6O7hDKwjI0OnjgbwA=; fh=eMrzgfgiZR327fK0C660Q1EXN6up6vM8mng2FJyHBMQ=; b=PJeY5Qqa3t7hTY+K9gZbNXJhKhZGUollTx8O+sIq9rb+KpZyIU3kElLzFQFjQD4Gsl 87zWcIpHObVVjOAwlYOxqpdJKbApjrzoLz0uVrcYcT3SB/sjp50RSStHk+cthdAd2S7r NEf4Z5bVs8kmZquTkQMP1H0o1GhAfC7NPT7zJyjpAfeylgH08JqyK5r4uCLrkyi8QVIV Pv8i26x2QQJ6Rx7tX2e//u4fFPHZUUumjmah1nEi/fYRq7ZGbkc8ruGlPtIfp0elvvZ4 od5OGxyHKrCj9em36hPkWTJKxlfrPtwpILhlvg8H8HFE7CHiIFGbpTjq5uThIDlobhDQ Kajg==; 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=1780640632; x=1781245432; 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=S5ptTmLxALvEKlrM8rvgH3TzuV6O7hDKwjI0OnjgbwA=; b=bdQ4XZHJawrKRO+/KZzUNqHPFL/WeOkxFmfajYxC4fnPyQJqPJa07FDg1rGfdwPvgC jAqnhvEKzvwHsqndiiszVSkL9DLEWKtba7VZf7+BRxRdAYmA7SaDSSlyLmrbejljRvO3 Zgrh1x4e7jP8prPw/LpVrE/8y82d9CRt09cwV8x5/yRx1L2Duah7f8iWdtVYyZxr+7A+ 9VnRn3Ep+eFg395hHnM6id6njWaIUPaX4MLmftXRUf6nxrLn7xXe1yCvfOet02USSOyR tp4WiRfxou81JHlP5eG3OuhHwOt/HzExZzZr2fANsXQIartIUQyUWOJ7ScKYyEIdTIVg pY0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780640632; x=1781245432; 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=S5ptTmLxALvEKlrM8rvgH3TzuV6O7hDKwjI0OnjgbwA=; b=Nx0z1nTqaVfri6mLGNR9MEd5SS7ROp+jvkgOlnZf542cgyaDuF9XVQwtAC8GL7gLAb KZvjDmbrV5DYwayWMk3T03RwP6pv6hSLxsbKTp+IDpbNpc+47klC9F/wKpfw5XcB/YMN Iat4WwEfGfpe9bINed8oAH5zFUn3HwB/r/na10cu2rth62ZBqqCliY2ww1DxobWONQ1G PF3o8RG1AqtRtEPz43yeSo9C0jc1OA8ZQbar4nNU+hAYa+VQy7261xY5+Jw8Qp51J9QR hrmji6t2jprJyqR3+jaT497paSuBLx07jFYJIiTytMEi/X2bfxgZiHFLOhOlfy30qSRf 3y2A== X-Forwarded-Encrypted: i=1; AFNElJ9yrTar+N3phYDH3L8+0LZ2Cq7/MC8f5wXgHd5YAZ44/KumWNlteOHLpb0BeQ7MJeKamOy7JO4CwG6SmeVq@lists.postgresql.org X-Gm-Message-State: AOJu0YzCKThxp1r9B8pNwAfdqIATVa89qRVJnGzIEX6oh5XJT1mVmzuS e6sA7nx/OYy5DV1z7sMxkFsa13QNqH1/cEd9udN93aHhHgmx4dfbEVpKswKyFNjG5pVzMW59/Zf Sn2GCOIP8zenjKUood+T/JrIUy5HqvDQ= X-Gm-Gg: Acq92OEPu4ocjhM465kD6CPQggtUZ45HgBldJvhiFMoJhuALXnJkHGoIrayojHxEVCQ b7YZPO7yAhRSXnK1bNd+9StsaNtJTn+dXdgXRlFxzWpnh6tQZHeb8OUSOnZ7KSJRFdwGO9dDHfQ TvMpBOXqG6/Yj6t/wadBKpIM9Xa1g4upiTUxxnj55rTsfcHjb4KKDx/3ri/W9EW7u86lHGWgqz2 OMNrFzJZuQII6MuhRl6lrZyfXPTjeB93Us9oaJfb51GPokzuWcVmGbcDNkk1hZLbt0fiUBUinvh WaJZ8G319+pJPZj3+J4= X-Received: by 2002:a05:6512:b91:b0:5aa:7023:8614 with SMTP id 2adb3069b0e04-5aa87c4014dmr572325e87.38.1780640631377; Thu, 04 Jun 2026 23:23:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 5 Jun 2026 11:53:33 +0530 X-Gm-Features: AVVi8Cf7qNvbmzouY904zfnGffW0rlr4tmewl3K35d2GPPJmT3rcOwgKf2UxUIw Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: shveta malik Cc: vignesh C , Nisha Moond , Amit Kapila , Peter Smith , 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 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 CL= T: > > --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 data= base 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? [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."))); + --=20 Regards, Dilip Kumar Google