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.94.2) (envelope-from ) id 1s4mM0-000vrh-4m for pgsql-hackers@arkaria.postgresql.org; Wed, 08 May 2024 18:49:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s4mLx-002NLk-Te for pgsql-hackers@arkaria.postgresql.org; Wed, 08 May 2024 18:49:22 +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.94.2) (envelope-from ) id 1s4mLx-002NLb-JU for pgsql-hackers@lists.postgresql.org; Wed, 08 May 2024 18:49:21 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4mLv-0003eN-1o for pgsql-hackers@lists.postgresql.org; Wed, 08 May 2024 18:49:20 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 448InHYT818433; Wed, 8 May 2024 14:49:17 -0400 From: Tom Lane To: David Rowley cc: Andrew Dunstan , Richard Guo , jian he , PostgreSQL Hackers Subject: Re: Revert: Remove useless self-joins *and* -DREALLOCATE_BITMAPSETS make server crash, regress test fail. In-reply-to: <815049.1715192644@sss.pgh.pa.us> References: <1e6ca7b3-98e6-46b2-9982-97f92c7523d8@dunslane.net> <76910.1715106055@sss.pgh.pa.us> <276516.1715121616@sss.pgh.pa.us> <279607.1715122556@sss.pgh.pa.us> <282081.1715123889@sss.pgh.pa.us> <815049.1715192644@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 08 May 2024 14:24:04 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <818431.1715194157.1@sss.pgh.pa.us> Date: Wed, 08 May 2024 14:49:17 -0400 Message-ID: <818432.1715194157@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk BTW, now that I've wrapped my head around what's happening here, I believe that -DREALLOCATE_BITMAPSETS is introducing a bug where there was none before. The changes that left-join removal makes won't cause any of these sets to go to empty, so the bms_del_member calls won't free the sets but just modify them in-place. And the same change will/should be made in every relevant relid set, so the fact that the sets may be shared isn't hurting anything. This is, of course, pretty fragile and I'm totally on board with making it safer. But there's no live bug in released branches, and not in HEAD either unless you add -DREALLOCATE_BITMAPSETS. That accounts for the lack of related field reports, and it means we don't really need to back-patch anything. This conclusion also reinforces my previously-vague feeling that we should not consider making -DREALLOCATE_BITMAPSETS the default in debug builds, as was proposed upthread. It's really a fundamentally different behavior, and I strongly suspect that it can mask bugs as well as introduce them (by hiding sharing in cases that'd be less benign than this turns out to be). I'd rather not do development on top of bitmapset infrastructure that acts entirely different from production bitmapset infrastructure. regards, tom lane