Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lH4xS-0005vu-I8 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Mar 2021 13:21:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lH4xR-0008OV-2Q for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Mar 2021 13:21:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lH4xQ-0008ON-RH for pgsql-hackers@lists.postgresql.org; Tue, 02 Mar 2021 13:21:00 +0000 Received: from [64.147.123.31] (helo=wforward2-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lH4xL-00063J-KB for pgsql-hackers@lists.postgresql.org; Tue, 02 Mar 2021 13:20:59 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.west.internal (Postfix) with ESMTP id 333291581; Tue, 2 Mar 2021 08:20:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 02 Mar 2021 08:20:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XToW8oZuRsXqoAAJI9kNOf82GxcVDmHcCRtFLzeml gk=; b=GqvpHjgCbVd50jZRVmSfJMtihSPPmCyJdUHFlVJpk783PB4ljTRBIJ2om 8enq2C+pepttJK3/y0A8HB3cuUjZ4+X2MfYiUq/ZXdnX87DLuxLABabghducf2xg E76/7wH482Ova1aPYK7MugJqP+/ieDGOzU9DapZi+BsiVMCpzUUt2jVP3FTT3Dtk TGAll7qxla9KIElr6ZjFA3DdieVQAyLWRoSKsm6N6qKiCNbgau1vN14AhfDryTLS WvA6jLWyfuDNyN2OV1gjjdp3zXTPAWqD1It22VF0LuNjDB02FDfxbbNrcAxCwPFR SIzeU/Lg9KUUViV+nwkNlFJ2CJ3IA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddttddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpefgfffftdethefhvddvuefg heehhefftdegvdduvdfgvdevgfduleefjeefgffgudenucfkphepkeejrddujeejrdeile drudegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomh X-ME-Proxy: Received: from laptop206oxuk.local (p57b1458c.dip0.t-ipconnect.de [87.177.69.140]) by mail.messagingengine.com (Postfix) with ESMTPA id B08F71080057; Tue, 2 Mar 2021 08:20:42 -0500 (EST) Subject: Re: pg_upgrade version checking questions To: Daniel Gustafsson Cc: "pgsql-hackers@lists.postgresql.org" References: <9328.1552952117@sss.pgh.pa.us> <20190327124351.GG12804@msg.df7cb.de> <29b364fe-b1f9-5171-6f78-1f01a94244ac@2ndquadrant.com> <3177834d-8313-c641-2d20-f99d69d8b6ff@2ndquadrant.com> <3CE32AD0-678E-42A8-A2B1-C2A3EDDE15C7@yesql.se> <22906594-DDD7-4085-8318-595C0C9C75C6@yesql.se> From: Peter Eisentraut Message-ID: Date: Tue, 2 Mar 2021 14:20:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <22906594-DDD7-4085-8318-595C0C9C75C6@yesql.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.31 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 23.02.21 17:14, Daniel Gustafsson wrote: > This exports validate_exec to reduce duplication, and implements a custom > find_other_exec-like function in pg_upgrade to check each binary for the > version number. Keeping a local copy of validate_exec is easy to do if it's > deemed not worth it to export it. This looks mostly okay to me. The commit message says something about "to ensure the health of the target cluster", which doesn't make sense to me. Maybe find a better wording. The name find_exec() seems not very accurate. It doesn't find anything. Maybe "check"? I'm not sure why the new find_exec() adds EXE. AFAIK, this is only required for stat(), and validate_exec() already does it.