Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsybu-00080I-GS for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Feb 2019 23:34:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gsybr-0000en-LN for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Feb 2019 23:34:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsybr-0000Qs-94 for pgsql-hackers@lists.postgresql.org; Sun, 10 Feb 2019 23:34:03 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsybo-0008Jt-NU for pgsql-hackers@lists.postgresql.org; Sun, 10 Feb 2019 23:34:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1ANXrb1015840; Sun, 10 Feb 2019 18:33:53 -0500 From: Tom Lane To: Thomas Munro cc: Robert Haas , Jakub Glapa , Justin Pryzby , Fabio Isabettini , Arne Roland , Sand Stone , Rick Otten , PostgreSQL Hackers Subject: Re: dsa_allocate() faliure In-reply-to: References: <6f3fe9fa5a984dc19e40e79fbef45edc@index.de> <6c2e8a16999f4e17b975d7369f6605b4@index.de> <45C7466A-7D67-4BB4-829C-F66CBB2961DB@voipfuture.com> <20190206232110.GH29720@telsasoft.com> Comments: In-reply-to Thomas Munro message dated "Mon, 11 Feb 2019 09:45:07 +1100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15838.1549841633.1@sss.pgh.pa.us> Date: Sun, 10 Feb 2019 18:33:53 -0500 Message-ID: <15839.1549841633@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > This brings us to a difficult choice: we're about to cut a new > release, and this could in theory be included. Even though the fix is > quite convincing, it doesn't seem wise to change such complicated code > at the last minute, and I know from an off-list chat that that is also > Robert's view. Yeah ... at this point we're just too close to the release deadline, I'm afraid, even though the fix *looks* pretty safe. Not worth the risk given that this seems to be a low-probability bug. I observe from https://coverage.postgresql.org/src/backend/utils/mmgr/freepage.c.gcov.html that the edge cases in this function aren't too well exercised by our regression tests, meaning that the buildfarm might not prove much either way about the correctness of this patch. That is one factor pushing me to think we shouldn't risk it. But, taking a longer view, is that something that's practical to improve? > So I'll wait until after the release, and we'll have > to live with the bug for another 3 months. Check. Please hold off committing until you see the release tags appear, probably late Tuesday my time / Wednesday noonish yours. regards, tom lane