Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHAPI-0003qx-SP for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Oct 2018 16:28:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHAPG-0001b6-RG for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Oct 2018 16:28:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHAPG-0001az-L3 for pgsql-bugs@lists.postgresql.org; Mon, 29 Oct 2018 16:28:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHAPE-0002Fc-A0 for pgsql-bugs@lists.postgresql.org; Mon, 29 Oct 2018 16:28:46 +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 w9TGSPBq029353; Mon, 29 Oct 2018 12:28:25 -0400 From: Tom Lane To: Peter Geoghegan cc: paul.vanderlinden@mapcreator.eu, PostgreSQL mailing lists , Heikki Linnakangas Subject: Re: BUG #15460: Error while creating index or constraint In-reply-to: References: <15460-b6db80de822fa0ad@postgresql.org> <26974.1540826748@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Mon, 29 Oct 2018 15:44:15 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29351.1540830505.1@sss.pgh.pa.us> Date: Mon, 29 Oct 2018 12:28:25 -0400 Message-ID: <29352.1540830505@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Geoghegan writes: > On Mon, Oct 29, 2018 at 3:25 PM Tom Lane wrote: >> Sounds like papering over the bug ... > I may have been unclear. It would be papering over the bug if I went > ahead and did that now. > The advantage of getting the file size from shared memory is that it > doesn't leave it up to code like BufFileOpenShared() to find > everything through readdir() iteration, an approach that might not be > totally portable. We'll reliably fail if all BufFile segments cannot > be accounted for with the size-in-shared-memory approach, which seems > more robust. I wouldn't be surprised if that actually was the correct > fix in the end. Perhaps. Anyway, I think we agree that we should identify why it's failing before we decide on a fix. regards, tom lane