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 1o3qWB-0001Kg-5V for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jun 2022 02:54:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o3qWA-0003W0-2w for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jun 2022 02:54:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3qW9-0003Vr-Q8 for pgsql-hackers@lists.postgresql.org; Wed, 22 Jun 2022 02:54:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3qW3-0000G0-5g for pgsql-hackers@lists.postgresql.org; Wed, 22 Jun 2022 02:54:57 +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 25M2sl5J3168909; Tue, 21 Jun 2022 22:54:47 -0400 From: Tom Lane To: John Naylor cc: Robert Haas , Kyotaro Horiguchi , Justin Pryzby , PostgreSQL Hackers , Thomas Munro Subject: Re: pg15b1: FailedAssertion("val > base", File: "...src/include/utils/relptr.h", Line: 67, PID: 30485) In-reply-to: References: <20220519193839.GT19626@telsasoft.com> <208993.1652994963@sss.pgh.pa.us> <20220520.120014.1649415417205853644.horikyota.ntt@gmail.com> Comments: In-reply-to John Naylor message dated "Wed, 22 Jun 2022 09:49:50 +0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3168907.1655866487.1@sss.pgh.pa.us> Date: Tue, 21 Jun 2022 22:54:47 -0400 Message-ID: <3168908.1655866487@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk John Naylor writes: > On Wed, Jun 1, 2022 at 2:57 AM Robert Haas wrote: >> ... So we can fix this by: >> 1. Using a relative pointer value other than 0 to represent a null >> pointer. Andres suggested (Size) -1. >> 2. Not storing the free page manager for the DSM in the main shared >> memory segment at byte offset 0. > For this open item, the above two ideas were discussed as a short-term > fix, and my reading of the thread is that the other proposals are too > invasive at this point in the cycle. Both of them have a draft patch > in the thread. #2, i.e. wasting MAXALIGN of space, seems the simplest > and most localized. Any thoughts on pulling the trigger on either of > these two approaches? I'm still of the opinion that 0 == NULL is a good property to have, so I vote for #2. regards, tom lane