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 1wWa53-002iM2-0M for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 13:31:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wWa51-002YKS-1k for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jun 2026 13:31:51 +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 1wWa51-002YKG-0Y for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 13:31:51 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wWa4z-00000001ybD-0vZS for pgsql-hackers@lists.postgresql.org; Mon, 08 Jun 2026 13:31:50 +0000 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-5aa68d9d56fso4316489e87.2 for ; Mon, 08 Jun 2026 06:31:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780925508; cv=none; d=google.com; s=arc-20240605; b=at/FaJd8Cr8rWS/7HCHLTbkklBzdYGAUAk7kFASVibMP1UoL6ERH9SxIO8EW4XKEMF vcA69GCV0Ub/AG9TM6JHxj4ohPhkOB8BOJ5Z4FzBeLLm2/kfr8xW7BGgc9Oh+OhtBdaa 8Ad83lpRPLKSX9CpafJQaNSmcZRb5u6aHoBcPenjWfUazzBdtyywOnJSj0e0jwom9pKg zmIRMjsoXwppYs9fi3XfjZfLmWYTXPm/0kl3918UdCmLwsAJaxW7kW0O84ckTGD7vcoO W1sEV2F3+boud79YscGMR1Xf/Y/8bc2d6/AAsm1dQCttl5fQLRfQ/2UZPSRgAPo8wHRs n+uA== 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=tdriV41PG7Gik1wv5vgOUaRsQsREBbQwtSPaA9WjzHI=; fh=5yuNqMarnBwQxGrIQ1WsU51IxSJrXfwklMU6cjNKJJI=; b=J75TszGnSy8H8PvEyIJj15aphHRAfw1Xh7JIVLsMU/o5aFv6U0/nmXTpQ7ndkcb7k8 5NpzsngCqJtHYQ88EVuED+cn8IQV5mUDnqKoJAMlPlxjC/AgWgmeKZ+13d0Zf3imeDob nH8Gbo+Uue669pUgubJqKkG+dLbjqJjNq2SMko28jKEPae3rGOH3JWAGHvd77iT3XKs6 Ik4/DEs6kd8Zgy2R0ercA6PnvhJq+s3Elqp2Oogi4EaEOFoNtkEAxccRq3dVuoJMNhB3 /uu9ofV+27p2hHI4r6S8tMzW+zCrllJebFaOUpfgxUn8nuGvDh4tjl+dtEsGNtagz4GP ppsg==; 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=1780925508; x=1781530308; 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=tdriV41PG7Gik1wv5vgOUaRsQsREBbQwtSPaA9WjzHI=; b=eXiyePJ01rA1RDk5hU66BYRkt/FcFuu+Bk1m1eeclFWaNErTQu8Kwc1+JOy5Y46TIi 2eWa+1Varvy/0fR51mDU/qDY34WkLhjkfPjEVsaUjr3wgazTeVHR3LAht4UoxN2lEkNT KpcCr/qqQkq6u1lbSsTUk3x2pMkC1Q/f/IgykMOqpVMdHIYGOlyzPSe4/1DLaVFXc0Ni ev41/eCeFCaA6NtdhEHBm9JwPfzXBHWbmRo9fOL+Jt6ROwZrY9K4TQT5FQS52HEJ9DRd Ys8ppvc/r9dpvz/1ESd66FKFKuZwrtMLlXyxeAReUIOKO6iE/iqi3sfxWCq1K9SCvFpT twfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780925508; x=1781530308; 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=tdriV41PG7Gik1wv5vgOUaRsQsREBbQwtSPaA9WjzHI=; b=h0DxNnsO1jzdIImHTk+KCvUqxBHOHcToOrzdHnp09EYQQsyN3VtK4hNxAbRo4AjdVY WXRG2VDI8X+9WKKuoKL0kmchdgNTrrqMRzCB7Q+rYZhKHJawFHvsdhAFCBVKEIZGq2Ux F8Daunnvp2OghQdZT4gNa1HTFxXF/gX2nHxyYgyLjwcmnqi5s0RDpvTh1esooBb3RfLK Gs/2sXHnfg0uNF3wmfUuLEegkKKRY4tu3pAk6YYn7iWfwCKiZQxxmI+j2QvifXgawfmu Vg7DmPYcCG0GlzfVTS5jvS2qVfzBZt94ANNoKPlPbmXimVfDDFklerVUNNRz8iTiagGD LP2Q== X-Forwarded-Encrypted: i=1; AFNElJ//B2ie6aT245HwrxwdUsp55wVfEWdUJ8Mb/+sVUAlRUrW8PTH7Bx52YHGa0yCKXcOZKszTMol3EYXtGVNB@lists.postgresql.org X-Gm-Message-State: AOJu0Yx8HVN+ImCWSVCm4eiXgUJcvuPDTibvsqrdWIU9DePHtdOz1vmV Rl9Eg2vFBfV6gYgfX6DbqVTyM/ScfXday9P4qlJip5YXEZ7LmQtIB2b0RkKi9vkG1eYi25rv9ns 5ytMFPUeY0Sl7bJQ0d0Kj7eDFRZz6qWc= X-Gm-Gg: Acq92OGnrt8mpRFOTnjTnuDXNySAsCcHlWUBrYx2ymCYcATMw8vQ4/8XJs2bdD4XvkR kcR+UrjjoVhi1bLYGjpWeHq9W+nHRXEaE51jkvIyVNPFr6eevcDSmoW4r4aIH2pjp/nMyO9jnZS l6aNiv+o4sQ1F7PXnitoN3T07eIubw+DmI096ThRs89H7BrWLKwbbSX0Y5QdWQ7RH1fqlNv3my4 ewVQeEmgMklxL2PsHzVAYTb8XNWjNekNwun7t1IMSTpyFno57cONpJmZQPBhJgIJ5E0OckhKybU AGt8ry8RQKX0XXOdLeI= X-Received: by 2002:a05:6512:61d3:10b0:5aa:6b85:85cf with SMTP id 2adb3069b0e04-5aa87babf3bmr2847065e87.10.1780925507661; Mon, 08 Jun 2026 06:31:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Mon, 8 Jun 2026 19:01:28 +0530 X-Gm-Features: AVVi8CflLncOKAQhOdxz7bpWK-a6vCdEjQ2AQyk5V1xTb3sud2_gRFhp_ss8Qas 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 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 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: 2= 47433. > > > > > [247433] CONTEXT: waiting for RowExclusiveLock on relation 16482= 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 on = CLTs, > > > > > similar to how PostgreSQL handles TOAST tables? Or does anyone se= e any > > > > > legitimate use-case (I don't) where we would need to allow explic= it > > > > > 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 t= o > > > > 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. 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. --=20 Regards, Dilip Kumar Google