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 1pw252-0006wg-82 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 May 2023 14:43:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pw251-0002ZI-2d for pgsql-hackers@arkaria.postgresql.org; Mon, 08 May 2023 14:43:11 +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 1pw250-0002Z8-0e for pgsql-hackers@lists.postgresql.org; Mon, 08 May 2023 14:43:10 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pw24w-001DYY-Lc for pgsql-hackers@lists.postgresql.org; Mon, 08 May 2023 14:43:08 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A01BF5C00B3; Mon, 8 May 2023 10:43:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 08 May 2023 10:43:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1683556984; x= 1683643384; bh=huYBruBLwA6Mt74PmiTLDtCD+jMk22510JECcKQ03+U=; b=P rlypovzSMHJSNWVyZDfgN74bHTOdjIuyGlF70nNWBwlxH7qZS4bmUBp/2GkJD1GQ SiFJjWCvRK0pArDPNYAvJlbCrCQlZ3e23yBqADcS/yBloQgyzWbZ2NjtRq6+Jgei jCgJmJw2baxIbk2aUQKobVDqN8fZBfwHIJRiZq9Lq5MeVXC1b8rosdZWGZTHrYQ1 wBkiQrfSLo7qjBzFf4VRJ+DjNP2bJPyxi0fI2Btv225lQ0WX2oFtjbl8VNJ1mXBP OZ0dFKrXZ4kYDjGRzVgQ0ap3+KYWrWBsv2NsEmaWiY4KGhE1WOgpEGgX9vGwwPFI CzCjsO71zjd3G/ipke0Zg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefkedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepjeehveetveevgeeghfegffduieefveektdekkeekteef gfehvdevhfeljeefuedvnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrghdpvg hnthgvrhhprhhishgvuggsrdgtohhmpdhtfihithhtvghrrdgtohhmnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlh hvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 May 2023 10:43:04 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C2E86149; Mon, 8 May 2023 16:43:01 +0200 (CEST) Date: Mon, 8 May 2023 16:43:01 +0200 From: Alvaro Herrera To: Yurii Rashkovskii Cc: Stephen Frost , Peter Eisentraut , Tom Lane , Robert Haas , Greg Stark , Andrew Dunstan , pgsql-hackers@lists.postgresql.org, Cary Huang Subject: Re: [PATCH] Allow Postgres to pick an unused port to listen Message-ID: <20230508144301.tr2kvlihqddwp6ss@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Apr-19, Yurii Rashkovskii wrote: > If we consider this path, then (if we assume the format of the file is > still to be private), we can make the port line accept multiple ports using > a delimiter like `:` so that the next line still remains the same. This made me wonder if storing the unadorned port number is really the best way. Suppose we did extend things so that we listen on different ports on different interfaces; how would this scheme work at all? I suspect it would be simpler to store both the interface address and the port, perhaps separated by :. You would keep it to one pair per line, so you'd get the IPv6 address/port separately from the IPv4 address, for example. And if you happen to have multiple addresses, you know exactly which ones you're listening on. To match a problem that has been discussed in the lists previously, suppose you have listen_addresses='localhost' and the resolver does funny things with that name (say you mess up /etc/hosts after starting). Things would be much simpler if you knew exactly what the resolver did at postmaster start time. > (I consider this feature so small that it doesn't deserve such a lengthy > discussion. However, I also get Tom's point about how we document this You should see the discussion that led to the addition of psql's 'exit' command sometime: https://www.postgresql.org/message-id/flat/CALVFHFb-C_5_94hueWg6Dd0zu7TfbpT7hzsh9Zf0DEDOSaAnfA%40mail.gmail.com#949321e44856b7fa295834d6a3997ab4 -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Every machine is a smoke machine if you operate it wrong enough." https://twitter.com/libseybieda/status/1541673325781196801