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 1wWTEV-002daf-1r for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 06:13:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wWTEU-000zsd-19 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 06:13:10 +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 1wWTET-000zsT-3C for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 06:13:10 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wWTER-00000001rHF-2jbi for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 06:13:09 +0000 Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-c86215c4122so270162a12.3 for ; Sun, 07 Jun 2026 23:13:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780899185; cv=none; d=google.com; s=arc-20240605; b=T9YNrTAYs8qlPv+RvH5shN17KiegMF7mPJMs6iB4NNJARURmoEDB+9iYVkL3JdvS99 wu2xu9Lru2OyKrt84zcI/nYvvYDGg+gh4Skqo4RutSbp5NbBTscRAQISF22Oo4ELB1z2 VtK+KCDo6r7Is+MeeX6dC6L6PndZ2R9jXA03ewwMPLLiQKkOvdr0ttWfCS8hMtHnBMv/ VtlpSmB0ebuDRO73estG1lNUnyobLtykRnQ5F3GDb8riLpM2pjYj/SMbDUa3+4EOpRXt Qr8TiUzxJCLexbD9c7cc69Z6h4JS5OqUimI03mzhJjcRrCbWB1Q5BMnATufM7lZ5X307 G6Bg== 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=lirj6TbWOwPyJiRplGGDN8W8sB+5Sz3rs+UVYvHuk/E=; fh=09pp+vIcEv0IUwm70Dsva1WPEaHjca/gnJgXzlDm1bA=; b=Uyeu4TX/sy21bOS8SZM+vdo7R0QrgyTDSfEj595RdXxHcR7avBP3Rt3T24EsKcEkr2 knKchwsPqIj9/g8fB3pfkmb16MkLzYEQVGkqiXfnTlsLqmJB48jaIiWZbZzQ1ztdZHKy 0sYeu6SzlQZwXg7yTfMWxtZop6P0ksbHiHkKMuJLoasefAw2nVqw9DpfW/2ZsnYzG9+A FnwSWe9vV6ie/Iuxv6Vrtplkq5PNRg46Mn3VEiv8HKD/ALzu2eCzllzlhHQf2v9LSP5A TAWVfOm12m2EYi/EwVHVk9bhDNDgAYMMgK5woFRp/qzQMUflYfu/U5uPrM2LCgORDpzo nKXw==; 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=1780899185; x=1781503985; 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=lirj6TbWOwPyJiRplGGDN8W8sB+5Sz3rs+UVYvHuk/E=; b=X9kvmC5ISQKCTH2MyorgAZLdgwY0t2ByjoGMoj4iV0UyaHs6bQrSBx0/xJdwEEH9PK kltIj+b0V+srWR7wCmxMZ4MlraUpip9Q2dSjh69yowOEDs7JQ8rJFeehkNIcX/zHVayy cBsR2nwMoXC/vGekoB7Dx26odOcv82UlRtlEDVMSoPh7OHDpeFyfPfzwhhjLY/l92/SO yUlE/Mdmnux6PZYCLyouHVrR3GYQ0x5wC5CXqkU5UkfjFxdKhUED784ZbeFo8B6VdpEg URpj61snlWhzBnBlLmAMpDjEz5XVrN8ZDyNCV0dPWEOUez1DIsOhJAqL/NM7tHv7xXBb +5iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780899185; x=1781503985; 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=lirj6TbWOwPyJiRplGGDN8W8sB+5Sz3rs+UVYvHuk/E=; b=DDlUyY8YOtbJBEjXGsRQ6iMoNmvMU15Db08pFQxRknyyhTFrxmBtedKU932mf+E40T JFTRoT5y20ehS46FHymJC/HBKkKyHkaxGe8l9FlbUvH5r1ONcMP7d4ce5yGvkEWWxvlp HPWA5sjpcjol1IM+VYYNdrfzs5xCvRoorvL08+qdGRHThAikhMewoUcTMDpw2i3V/tK/ dvv3kHzh0VecVEWghDwfV4SZr4PM1DPWaHC7+QxGj21G6K3aZwqfxkUPcS4zmy6rhnMs zA4bUeZ1BGtg+Jganre880DQWGoAhMmkhraIzYvCFMTwT3SQfPK51aBlF5tLijMLtsGZ UYCw== X-Forwarded-Encrypted: i=1; AFNElJ+L0dPLTxZRZmEuZ+6n+AiUAM7ai0xg2kfYbJx0BF0ONMC5F88hHlHjAig0iE0PigZ3GfjxphOdFCB8PjZY@lists.postgresql.org X-Gm-Message-State: AOJu0YyRFTMoZ23MX1w5mz2xKXGYg7+yHXxt2ccJRGaQneEEslEuKQwi j68iieDZaXz/fjdm7XmLds2kAcPmLzy7oWWlHFupOeTzTHZ24BsJ33G7vX/L5LT+othzwhrChOj sHwDF1KjgPSfkjxt6orlinHRNrMhHBBo= X-Gm-Gg: Acq92OET8dnfr+DcP7i7DE9LboXU9wmmigOPGbEMbYDVli6qC5TrLmICkno7egm7FAf c/cCM5Fnhagq2YpMOetA71Sa+oVXwtHP8HnDJUEYIuU8WXP8tvh/zdGWQJRqjVVmw9hX+VXBrvE O8CWhK+EvjnbcdcEATszEYQXhV1Ok3NLKSE1Ta3z6CDHmxs1NL0QTj2P2jlPSNCQq/GXlinAavj KrxJJvxydvmtIBlo7YEPrKiTrsVGYlbnc2pFRveIgj6H5+YW4qoU40TcTWOsyr9lKpIsn9HQwKL MJbuFNzi4WgNUvcX8CX/sNQdCtX1hdphrOKvkFZ/GdIXorgW3ryGxB3yreVlmHc= X-Received: by 2002:a05:6a21:4688:b0:3b3:bdfd:762c with SMTP id adf61e73a8af0-3b4ccd77cd5mr16548041637.17.1780899184723; Sun, 07 Jun 2026 23:13:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 8 Jun 2026 11:42:50 +0530 X-Gm-Features: AVVi8CfvJaCM8FgdELzMvRefAPlYPtt8Ov9DTwHflAHM1fTosTNjO-fP9uC-Zpw 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 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 locks o= n 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: 247= 433. > > > > [247433] CONTEXT: waiting for RowExclusiveLock on relation 16482 o= f 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 on CL= Ts, > > > > 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 > > 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. 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. thanks Shveta