Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d53Lb-00038V-7i for pgsql-hackers@arkaria.postgresql.org; Mon, 01 May 2017 04:54:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d53La-0002gG-Kf for pgsql-hackers@arkaria.postgresql.org; Mon, 01 May 2017 04:54:06 +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.84_2) (envelope-from ) id 1d53La-0002g7-9e for pgsql-hackers@postgresql.org; Mon, 01 May 2017 04:54:06 +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.84_2) (envelope-from ) id 1d53LX-00015W-Cz for pgsql-hackers@postgresql.org; Mon, 01 May 2017 04:54:05 +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 v414rn9O027355; Mon, 1 May 2017 00:53:49 -0400 From: Tom Lane To: Amit Kapila cc: Craig Ringer , Heikki Linnakangas , Andres Freund , PostgreSQL Hackers Subject: Re: OK, so culicidae is *still* broken In-reply-to: References: <4180.1492292046@sss.pgh.pa.us> <6309.1492611331@sss.pgh.pa.us> <20170419153151.y5bfp4kdo377ycps@alap3.anarazel.de> <20170420192500.gaagaaopc2kjmort@alap3.anarazel.de> <20170424180848.gxaw44jwag7doqz5@alap3.anarazel.de> <1784.1493059391@sss.pgh.pa.us> <20170424185029.xm5yjkrifajcmmco@alap3.anarazel.de> <15162.1493129233@sss.pgh.pa.us> Comments: In-reply-to Amit Kapila message dated "Mon, 01 May 2017 10:18:47 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27353.1493614429.1@sss.pgh.pa.us> Date: Mon, 01 May 2017 00:53:49 -0400 Message-ID: <27354.1493614429@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Amit Kapila writes: > Yeah, that's right. Today, I have spent some time to analyze how and > where retry logic is required. I think there are two places where we > need this retry logic, one is if we fail to reserve the memory > (pgwin32_ReserveSharedMemoryRegion) and second is if we fail to > reattach (PGSharedMemoryReAttach). I'm not following. The point of the reserve operation is to ensure that the reattach will work. What makes you think we need to add more code at that end? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers