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 1wV4Jl-001f4b-1L for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 09:24:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wV4Jk-005plx-05 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 09:24:48 +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 1wV4Jj-005plo-2H for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 09:24:47 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wV4Jh-00000001DDu-2O8z for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 09:24:47 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5aa61e3d3f3so472341e87.0 for ; Thu, 04 Jun 2026 02:24:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780565084; cv=none; d=google.com; s=arc-20240605; b=iEWXVdtho0GylBfZ9ZClJhuw4s2bT4yKtuj9xE/JuU7cCX5NxGiAXoNRSfDFOjZ+RV 81b/A+dA2UaSGrSpGZi7Jd2vPSNMtzcK7xBiNHBFSbcAtw7Wo0fVZ6UGzMQO2+RFfzim rzDv/x/04JMZi1eXgthbH0nUlqqV7ye3UjtWKxgyUXLF6h0wiNA5/Gu8V1KHOHhIkC4A PVVNF15YNV2xd4BDxrdsSJOWw4qXCsGfEi78lY7SG7I/DZD56fWNaq5AbOzlLjXJ1lkI gg56uDjul439fb0EAYluL7w45wt5jiSou8m5HdHUYmaAEpsZJiWHGwRTl0rOyi9uh0YR LLuA== 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=UyAbMg8vITjoZ31vLk22aAytToUDgkEi9PJ6bcktKek=; fh=1Bdy+2q/4WvTDsdtlGReNtS2SMa09asmzt9dqWBnHbo=; b=D17LpMJEXi9Ui1eDJ/k1R4rgRlguE/RE5/49tcCN2sr24dqoYRNiwuciCiJ9x/mC8y /cMA0UD24Kf5o/Bfu0e9Itd9yQS2sL6ry1/O9gvmuFbc+XrYbN+LGs5qTIVh6BULbomp +72koPb6/nc4azYAAl9s8zlMIpwtW1AWiYrbymxBc3/NfacPPWScwxtY4HsDj0djjjPv de+7Y+xtoSBUPpyZyBBUsNM/q+6nBHGJpK51e5am6i4qgUIkbIx9Rbtjf2gKlRbSyXtt hWSMwC3CERMgt1eQJza4nm5M1M5G8lpVgXJqXGTqO++jeZfw+/aBNLiYSd/nbR/X4Jpx QqGw==; 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=1780565084; x=1781169884; 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=UyAbMg8vITjoZ31vLk22aAytToUDgkEi9PJ6bcktKek=; b=OJSrPqNqQkZrTusrGsECjg+UMKD7LyttZXCu1E4t4CG01D4o1D9ZJ3Wxv8k7UYq5V3 Mnl1gWcoZ0Wv6WP8nWx7ZGaeWZkiyPlGMNdWJ1jNPxR0STfmnrQHuLqj3xLwctP+UkHs a9aLB4QWOFaXppAh1Scl4X7h9vLEcbxcZGqfUXjn9pn4PjRLeTYqjX33p2+atoUYFU6u s3nUYOHxlUOjRo1kvAvstO4Aw1LlUcn6/kobcWkt4jPX3Z4ursju40UsFkkX1UF3BLJg J8dt7xZoiLdyetGaTXqYRJrh8nsu+W/Cp77YG4QVRP4nXmvlPdgiy+dbrAHMd6uhsnpX WJWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780565084; x=1781169884; 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=UyAbMg8vITjoZ31vLk22aAytToUDgkEi9PJ6bcktKek=; b=KQ0l6Sf/vRSbm5rXcZVJAsWjofEwAzwsOWHSMXHPjKo7PXcwmrYv9MNCrUwfMnnTdJ H24g0nshdT1YTvLzB+DGAX1jzIqRCqOJZ5UB9VNG5fUic9RFcoMwbHXDrLJy57tGz0MU rgkPI2a/ysmWtTxr6vRTVsDnLdaydufdacScLxnc6A9/vez/UCGjiH6xc5iuJYR5aToc nNEE6+T0Z4c3Hp+FxZ+IH6jkeYArYHzrKQ4k9xfAm+8GAI+lilKOH5eY/kHcq4comjUL khe2XNtoIrjC/vpvY1eAdgrkD6kwNabOfU3zg7WlCCskh1IQRHw+2QuPxxW+tkDulYeG hmhA== X-Forwarded-Encrypted: i=1; AFNElJ/16ukWHZ3cbugSKM+FAsox9xnjL/9n9DRqC8CjkifOx5bCp7mlyH4d4LtJFeSGh5Rt+ahe6NdhjCaUlj/F@lists.postgresql.org X-Gm-Message-State: AOJu0YwZNVDd03w8XfKcboqSE0NFhG9dgzHcSJROUVak5GRxoWZ+LfNN IU+ybRbn11uRXRqKOzTK5vFjLe6V91dEzzC7ctOGET0ghMs57zsl8uBlTCBX2wX4bhGpu6IltzU tZT0Cz+3+/22zQUopaIX/KFgRmJkrGhk= X-Gm-Gg: Acq92OH8EEUxcGaJ+t1fzyduZqODRei4jPWskPrCMym8n0HkVvi0o1wkYUrzgdvkWxB T1Ji0t4PC3klJP02g61jUIf3KDQC6HgSp4FCv/eaT2y9a88GxgYYga4VGFpHG41Va6zEOzq34mF 7kAHZaQ19GrBzv9F0xDRKgJF9mwYmPv6h1a7AYDVD/I/y1AuOp5ujIDZm6LdyGJCp430x8BvKlt NpDhMlRN5ln3pOtTpa5P8JoyVI55g9VgKpmtMNFvNPxcKXMqdgtGt/KeCETzSlbI4Bjllxp0iT+ VetCDPbhCDwgtcsA1WruBH0RMK8uCfx1cgczWsVGp6RUKLB3 X-Received: by 2002:a05:6512:8055:10b0:5aa:6128:dfc4 with SMTP id 2adb3069b0e04-5aa7c0ff17cmr1735394e87.24.1780565084479; Thu, 04 Jun 2026 02:24:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Thu, 4 Jun 2026 14:54:26 +0530 X-Gm-Features: AVVi8Cfe-C57fSI4EAlKFW1txXumuOtqe9K4lXUZG5zPMQGPdkzVTNKxeDO7fQY 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 2:47=E2=80=AFPM shveta malik wrote: > > Currently we allow inheritance from CLT. I see 2 side-effects > > a) Queries on the CLT will always include rows from inherited tables. > Whether this is desirable or not is subjective, but it can lead to > unexpected results for DBAs querying the CLT directly. > > CREATE TABLE public.my_custom_extended_log() INHERITS > (pg_conflict.pg_conflict_log_16392); > INSERT INTO public.my_custom_extended_log (relid, schemaname, relname, > conflict_type) VALUES (99999, 'public', 'fake_table', > 'forged_conflict_type'); > > postgres=3D# SELECT count(*), conflict_type FROM > pg_conflict.pg_conflict_log_16392 GROUP BY conflict_type; > count | conflict_type > -------+---------------------- > 5 | insert_exists > 2 | forged_conflict_type > > b) > DROP SUBSCRIPTION may unintentionally drop inherited tables. > > When a subscription is dropped, the associated CLT is removed > internally using DROP-CASCADE. As a result, any user table inheriting > from the CLT would also be dropped, causing the user to lose any data > stored in those inherited tables. > > postgres=3D# DROP SUBSCRIPTION sub1; > NOTICE: drop cascades to table my_custom_extended_log > NOTICE: dropped conflict log table > "pg_conflict.pg_conflict_log_16392" for subscription "sub1" > NOTICE: dropped replication slot "sub1" on publisher > > OTOH, regular tables provide an opportunity for the user to review > dependencies and decide how to proceed: > > postgres=3D# create table tab1( i int); > CREATE TABLE > > postgres=3D# create table tab_i() inherits (tab1); > CREATE TABLE > > postgres=3D# drop table tab1; > ERROR: cannot drop table tab1 because other objects depend on it > DETAIL: table tab_i depends on table tab1 > HINT: Use DROP ... CASCADE to drop the dependent objects too. > > ~~ > > I previously thought inheriting from CLT should be acceptable as that > is purely the user's decision to create a child table for its own > purpose, but upon rethinking, I believe it should be blocked. > Thoughts? Yeah, I don't think there should be any use case for inheriting from CLT. IMHO restricting this might help us handle more such cases. --=20 Regards, Dilip Kumar Google