Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVh7l-0007vn-E3 for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Oct 2020 20:23:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kVh7k-0002U9-CX for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Oct 2020 20:23:48 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVh7k-0002Ty-5q for pgsql-hackers@lists.postgresql.org; Thu, 22 Oct 2020 20:23:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVh7i-0006L4-2i for pgsql-hackers@postgresql.org; Thu, 22 Oct 2020 20:23:47 +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 09MKNah9041308; Thu, 22 Oct 2020 16:23:36 -0400 From: Tom Lane To: Mark Dilger cc: Robert Haas , Peter Geoghegan , "Andrey M. Borodin" , Stephen Frost , Michael Paquier , Amul Sul , Dilip Kumar , Andres Freund , PostgreSQL-development Subject: Re: new heapcheck contrib module In-reply-to: References: <12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com> <20200420194210.sevnpi4lyghoanxi@alap3.anarazel.de> <23E60C3C-C20A-4508-84AC-E0CEA59E784A@enterprisedb.com> <5F743835-3399-419C-8324-2D424237E999@enterprisedb.com> <885D2EC9-7D06-4903-A17D-72C184A1E1C5@enterprisedb.com> <5CC85F28-F210-47AC-8DA8-EC4E82AF3FD5@enterprisedb.com> <0C0349EB-DD85-4DA8-82C7-DF70AB714592@enterprisedb.com> <9DF93B83-FE46-4EC4-A99D-77A60729FD2D@enterprisedb.com> <50F6468F-5A5E-412A-86EC-DF24B549D733@enterprisedb.com> <7D603B53-8078-4AF0-851B-803FF4416501@enterprisedb.com> <98265AA9-7BDC-4708-9348-CC1B173BBE1D@enterprisedb.com> <209783.1603313248@sss.pgh.pa.us> <77A60E99-6054-40FD-A5D6-769C287D4A0F@enterprisedb.com> <721BFA83-EA6F-463D-A9DF-CE78A318B73A@enterprisedb.com> <2A7DA1A8-C4AA-43DF-A985-3CA52F4DC775@enterprisedb.com> message dated "Thu, 22 Oct 2020 13:04:01 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41305.1603398216.1@sss.pgh.pa.us> Date: Thu, 22 Oct 2020 16:23:36 -0400 Message-ID: <41306.1603398216@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ... btw, having now looked more closely at get_xid_status(), I wonder how come there aren't more compilers bitching about it, because it is very very obviously broken. In particular, the case of requesting status for an xid that is BootstrapTransactionId or FrozenTransactionId *will* fall through to perform FullTransactionIdPrecedesOrEquals with an uninitialized fxid. The fact that most compilers seem to fail to notice that is quite scary. I suppose it has something to do with FullTransactionId being a struct, which makes me wonder if that choice was quite as wise as we thought. Meanwhile, so far as this code goes, I wonder why you don't just change it to always set that value, ie XidBoundsViolation result; FullTransactionId fxid; FullTransactionId clog_horizon; + fxid = FullTransactionIdFromXidAndCtx(xid, ctx); + /* Quick check for special xids */ if (!TransactionIdIsValid(xid)) result = XID_INVALID; else if (xid == BootstrapTransactionId || xid == FrozenTransactionId) result = XID_BOUNDS_OK; else { /* Check if the xid is within bounds */ - fxid = FullTransactionIdFromXidAndCtx(xid, ctx); if (!fxid_in_cached_range(fxid, ctx)) { regards, tom lane