Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ffb04-0006Wl-4J for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jul 2018 01:11:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ffb02-00055f-7H for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jul 2018 01:11:26 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ffb01-00055A-Sj for pgsql-hackers@lists.postgresql.org; Wed, 18 Jul 2018 01:11:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ffazz-0006Aj-8D for pgsql-hackers@postgresql.org; Wed, 18 Jul 2018 01:11:24 +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 w6I1BJR3018927; Tue, 17 Jul 2018 21:11:19 -0400 From: Tom Lane To: Robert Haas cc: Andres Freund , Michael Paquier , Justin Pryzby , PostgreSQL Hackers Subject: Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)" In-reply-to: References: <20180627233939.GA10276@telsasoft.com> <20180628020432.GB11054@paquier.xyz> <7317.1531694923@sss.pgh.pa.us> <20180716131337.usestwjviwwocpyz@alap3.anarazel.de> <20436.1531751966@sss.pgh.pa.us> <4993.1531773411@sss.pgh.pa.us> <14892.1531872065@sss.pgh.pa.us> <18006.1531875305@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 17 Jul 2018 20:59:14 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18925.1531876279.1@sss.pgh.pa.us> Date: Tue, 17 Jul 2018 21:11:19 -0400 Message-ID: <18926.1531876279@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Tue, Jul 17, 2018 at 8:55 PM, Tom Lane wrote: >> Uh, what? There are only a few callers of those, and they'd all have >> crashed already if they were somehow dealing with an invalid buffer. > Sorry, I meant Assert(owner != NULL). Oh, gotcha: so that if an external developer hits it, he can more easily see that this is from an (effective) API change and not some mysterious bug. Makes sense, especially if we include a comment: /* We used to allow pinning buffers without a resowner, but no more */ Assert(CurrentResourceOwner != NULL); I think it's sufficient to do this in ResourceOwnerEnlargeBuffers, though. The other two should be unreachable without having gone through that. regards, tom lane