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.98.2) (envelope-from ) id 1x9A87-00000001n17-3vqd for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Sep 2026 23:42:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1x9A86-00000002GVE-3SQ5 for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Sep 2026 23:42:30 +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.98.2) (envelope-from ) id 1x9A86-00000002GV6-2IH8 for pgsql-hackers@lists.postgresql.org; Tue, 22 Sep 2026 23:42:30 +0000 Received: from mail-dy2-x10.google.com ([2607:f8b0:4864:36::10]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x9A84-00000000l3V-15pX for pgsql-hackers@lists.postgresql.org; Tue, 22 Sep 2026 23:42:29 +0000 Received: by mail-dy2-x10.google.com with SMTP id 5a478bee46e88-339795849f6so82123eec.1 for ; Tue, 22 Sep 2026 16:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790120548; x=1790725348; darn=lists.postgresql.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=3FHg8su49/kzGsKUeW2IEeHdBJ26DzMq7s39EaE5MVQ=; b=VbgGM4OgitdE5W2VgMaRI8GkFJESsZSxa1BD7ycEDaU8Jhzs6DX0uLnKzHZYcvx3dw JxNp6RGsqlJKcvR2RqYOhc9H+ksryJ9Imbm3VhdxrlbtHtu9Xcu52b4KnYWoez9J57aN JXLA9bBuuPpEAUOLQBsj+Pa7/xCKKm4shJfpdWf9WQdQELZTvdYPzYopo2awHlWjmZJ8 Mz/zzoIciC9CVuOAQzm5UYLZa5BnZKYNwqtqf3bd4Iew0aBqg9QvMDwXjvEbljVrJQEU FJEBgBBeWDt0gg8aWVIGMowxzOJfejZwWHzqipkPF9Jl6TqR3QNkh38lSMhmf8gO26oO ceIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790120548; x=1790725348; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3FHg8su49/kzGsKUeW2IEeHdBJ26DzMq7s39EaE5MVQ=; b=FtpRUn0xiSfmwaUCw4/xYcLWQa0TRF3bEXFmIHzl/m4/KcWRvNZHhCHNLRtSsuZ0Q0 mi53wHG0zQ5CbyHBA3SFrmsd2A8CIzmDe0BtipFK0gr3UAgKkm/2sfrixNgcWEtv2z2l IyRpLqBYRKBGXYwQrteEezMr/ZlWaJJDyEoCYobY6lahIXXoYMjmnWP+ihs5vZp1qFcv k+8sPk4avPOYP5O7M3yjGnIfZr6fhf5+uljSjrLL72KiD9dv5Nv/yKjXt4UhQ/6N2WZn F8UbqnOTkl2lD1jb1SNU3DZwPAUN4i3dJJDnOW/0qIcUZv+sCAaaed6knkjiEo2lNTzk +4Nw== X-Forwarded-Encrypted: i=1; AKwUvBz0AKkR8aCOn4F8oRq93W/BXcr9a5KqhQuNQoqDC3LSYPcGyfHi1P8fjJKx65jfvbEVEEPVtt1lEj6nhZnH@lists.postgresql.org X-Gm-Message-State: AFuF++mkbEc4fA8hoc4HkmEm16v/cw0K49JlGjkAlhLAr7m441NFiDEa ZQRuv5bEL7sKG2QEps5A4+vffpSVdbaVZwKk49o5jC8vzwx8QO4LN2xp X-Gm-Gg: AYBFou16P2dFbrfXijostm2p+8D1j3JQT/ZLjr8LnFqwcctpBLc9oK8e5WxlhJfK+ya tND9EWbWVu9cGzRCbTGo0x/DLmR0NVT/GsTOvE++P1Ug4ATya77aXwpXSOpVzonW7DECzWMffA0 21I/km+uQ50CYJz8Lg0JD1citVSuBJNnlCHCPZScQsLOp/cIwogYX+maPmM8BOF0l5aJ8ksLW7Q tgvEpw2COBxEwxjoxxaZ092fZZ0BSQ1fWoyfRLjq/u3fw8UCIdPlctVp3oLqvREp2oMUassKxqX O6SvTzviLi5NDwzyr4ovFtH7i4VPenrcAI9oRNan2DNLwB0behz+iCF0qkgcR+/vUJhJkB0hAdi e7TRyvED2p47mfvLT4vPdTcOcenItVoHoG4XvRs60KsWdXwsGFVgUtDhaqAti6d/jxCR1B72E5C CYE5eG0cu9DhrABDQk+doGIq84GYU/EciqdgZs79/LFwl5y/euQS7B3UdSLpQIHKfeYdhm6QpYO NI4IxXtwqLLIxR9AM7Ysu3fLd6fWbEnZHplgTlaBWK+XT3HSkTXifC/1qG5Z2gH56CZ642KQnAq X4I/Vam5mPg3LaEVVrE/KnKG36k59yCeppXA X-Received: by 2002:a05:7022:222:b0:139:81c6:67a1 with SMTP id a92af1059eb24-144f91c419emr1878451c88.1.1790120547695; Tue, 22 Sep 2026 16:42:27 -0700 (PDT) Received: from 192.168.1.109 ([2803:3c90:cee:ea00:5c3c:7e70:29e3:7a55]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-33e939fe502sm1423748eec.2.2026.09.22.16.42.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2026 16:42:27 -0700 (PDT) From: Manu To: Amit Kapila Cc: vignesh C , shveta malik , pgsql-hackers@lists.postgresql.org Subject: Re: Distinguish publication exclusions in object addresses Date: Tue, 22 Sep 2026 20:42:25 -0300 Message-ID: <179012054503.688004.12375093780155765376@gmail.com> In-Reply-To: <179011994715.485930.9380133175707344860@gmail.com> References: <179011994715.485930.9380133175707344860@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Correcting myself before you spend time on this: I wrote > Of those six, the regression tests currently reach one. and that is wrong. I had inferred it from grepping the expected output for the EXCEPT message, without measuring the code. I have now built with --enable-coverage and run make check. The ereport() call sites in check_publication_add_relation() come out like this (gcov execution counts, master): incomplete detach never executed individual partitions 2 relkind not supported 2 system tables 1 conflict log tables 1 temporary tables 1 unlogged tables 1 So five of the six already execute. They are reached through the non-EXCEPT path: the same ereport() runs with the other errormsg, from the existing "cannot add relation ... to publication" cases. Only the incomplete-detach one is never reached at all. What my patch actually changes, same measurement with it applied: relkind not supported 2 -> 3 system tables 1 -> 2 temporary tables 1 -> 2 so it adds three executions, but not three uncovered lines. That weakens the case I made. The honest version is narrower: line coverage of those sites does not change, what is untested is the EXCEPT variant of each of them - the message whose quoting vignesh just fixed, and the schema-qualified name it prints. Today exactly one of those six paths has an expected output containing "in the publication EXCEPT clause", the partitions one. Whether that is worth three test cases is your call, and I would understand if the answer is no now that the coverage argument is off the table. If you do want something from this, the incomplete-detach site is the one genuinely never executed, though reaching it needs an interrupted concurrent detach and I have not tried to build that. Sorry for the noise. Regards, Manu