Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6NeG-000691-Nu for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Nov 2016 20:14:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1c6NeG-0001sW-Ar for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Nov 2016 20:14:36 +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.84_2) (envelope-from ) id 1c6NeF-0001sP-Pk for pgsql-hackers@postgresql.org; Mon, 14 Nov 2016 20:14:35 +0000 Received: from [66.111.4.28] (helo=out4-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c6NeD-0007ib-BA for pgsql-hackers@postgresql.org; Mon, 14 Nov 2016 20:14:34 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D03512070C; Mon, 14 Nov 2016 15:14:11 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 14 Nov 2016 15:14:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OaH2ZqTawI2b1D Rj4Y+Yi6xxnS4=; b=VJgWp/B2ohJTSXr/Q6fBxhOPAHoHHAVnfbfdSixxG/+JQR Xa/+AWVwibbbWBmuHkssx6K+nAICw2RdGDM6h7yJ+l1hdZnHn4XmZ8zdcNG3nlnJ AXnVm3J2MDyzOwLAiUKtt+3AqWnppk4WYnHJvTqED4RRgkGOOmX/tDabLLGw0= X-ME-Sender: X-Sasl-enc: /Qm/JaXAD51Xf2ui1Z3OFl0BOSodehLGODZ/+x6MvvvQ 1479154451 Received: from intern.anarazel.de (unknown [50.201.8.0]) by mail.messagingengine.com (Postfix) with ESMTPA id 899042442F; Mon, 14 Nov 2016 15:14:11 -0500 (EST) Date: Mon, 14 Nov 2016 12:14:10 -0800 From: Andres Freund To: Tom Lane Cc: Amit Kapila , Ashutosh Sharma , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated. Message-ID: <20161114201410.ctgglamtdu2u5yj3@alap3.anarazel.de> References: <20160830023140.tsesenk7roajx3ak@alap3.anarazel.de> <20161112130408.kfsxcbkqo2b3nvuq@alap3.anarazel.de> <22432.1478968242@sss.pgh.pa.us> <20161112163508.5uqlaozeyr3l56ae@alap3.anarazel.de> <22899.1478968932@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22899.1478968932@sss.pgh.pa.us> X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.28 (deferred) X-Pg-Spam-Score: -1.8 (-) 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 On 2016-11-12 11:42:12 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-12 11:30:42 -0500, Tom Lane wrote: > >> which is a rather blatant waste of cycles. I would suggest an explicit > >> do-nothing installcheck rule rather than the hack you came up with here. > > > I had that at first, but that generates a warning about overwriting the > > makefile target - which afaics cannot be fixed. > > Hm. What about inventing an additional macro NO_INSTALLCHECK that > prevents pgxs.mk from generating an installcheck rule? It's not > like we don't have similar issues elsewhere, eg contrib/sepgsql. Well, that one seems a bit different. Seems easy enough to do. Do we want to make that macro that prevents installcheck from being defined, or one that forces it to be empty? The former has the disadvantage that one has to be careful to define a target, to avoid breaking recursion from the upper levels. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers