Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxxas-00075j-Cw for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2019 18:01:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hxxar-0002ZQ-90 for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2019 18:01:53 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxxaq-0002OF-6S for pgsql-hackers@lists.postgresql.org; Wed, 14 Aug 2019 18:01:52 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxxan-0004mD-4Q for pgsql-hackers@postgresql.org; Wed, 14 Aug 2019 18:01:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id A864554E; Wed, 14 Aug 2019 14:01:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 14 Aug 2019 14:01:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=nWq0X61D2QrVMieG+tAgc+bYfqN 2PcLrX6NE8cuJjWs=; b=DCftq9CFMFHGOJretRmLGDHEUSV24jQqiBIdAO6TKH7 lOmN36XD+flADgbD5EABPE7xFiQz/6/Tcc0LkoOotVaRmpNXWEOZBYngN0T4GSCs 2geKWoqWyYvTKeOIXLo3voaLO8QB1QKuitH/XeeAlE34w/Y9IwLHgp65qLjB0hH1 mRUGginXQZyZmy2hkHmqJTlL0cvMlnk2AlNQ7p36Lt1g+YQzaxj8h2zF6mGHXdHl pAw/9o3zOePiwSslLcSfoqCFOQhaY6b+mu4WyFeUU1naFGicSBHFtuiOCga8bBEN sTvIlDsk6txsJSEtPtFgjVJoBajX9slqARbV2sT+7Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=nWq0X6 1D2QrVMieG+tAgc+bYfqN2PcLrX6NE8cuJjWs=; b=fowMryaSAUkRLx6/ipp8Xc f8VTEuMnvdfplLtZlblRRRPSGoDl/FL5FbFkBf5fRonJ+uiAm1YJlkkJENe2lZpL sWfF+uEFamc4VmDMuIbCNmF916nqxZdSU/vuwxbuJBrc4KfQzc1XTEqhZg0PCnSy 1yLRHt68Eb9NlPjfxCWJBDQTsIRTZsCMpwAbVafEoHDsQDCjdD8CX+ewWXwk0/y5 2XlD7x9FEmX26fVtquaLggBjvTXhdDxrPaB7pkC4Kvi1rjZ/uDLJNvB7CIf40kLE bZNizwDNRByjZcfJ8jCYoognmH1kt1nPmSgnwYGB+topgt4x8KbILfzAGQqgO9sg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvledgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucfkphepie ejrdduiedtrddvudekrddvfeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgv shesrghnrghrrgiivghlrdguvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-218-237.hsd1.ca.comcast.net [67.160.218.237]) by mail.messagingengine.com (Postfix) with ESMTPA id 2648D380076; Wed, 14 Aug 2019 14:01:45 -0400 (EDT) Date: Wed, 14 Aug 2019 11:01:43 -0700 From: Andres Freund To: Tom Lane Cc: Feike Steenbergen , PostgreSQL mailing lists Subject: Re: Feature: Use DNS SRV records for connecting Message-ID: <20190814180143.62533ohqlaqcl7so@alap3.anarazel.de> References: <7386.1565707387@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7386.1565707387@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-08-13 10:43:07 -0400, Tom Lane wrote: > How would we get at that data without writing our own DNS client? > (AFAIK, our existing DNS interactions are all handled by getnameinfo() > or other library-supplied functions.) > Maybe that'd be worth doing, but it sounds like a lot of work and a > lot of new code to maintain, relative to the value of the feature. It might have enough independent advantages to make it worthwhile though. Right now our non-blocking interfaces aren't actually in a number of cases, due to name resolution being blocking. While that's documented, it imo means that our users need to use a non-blocking DNS library, if they need non-blocking PQconnectPoll() - it's imo not that practical to just use IPs in most cases. We also don't have particularly good control over the order of hostnames returned by getaddrinfo, which makes it harder to implement reliable round-robin etc. Greetings, Andres Freund