Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g2mMZ-0005pp-TF for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Sep 2018 23:58:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g2mMY-00086A-53 for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Sep 2018 23:58:30 +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.89) (envelope-from ) id 1g2mMX-000863-08 for pgsql-hackers@lists.postgresql.org; Wed, 19 Sep 2018 23:58:29 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g2mMU-0006sm-1m for pgsql-hackers@lists.postgresql.org; Wed, 19 Sep 2018 23:58:27 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3D90F20A70; Wed, 19 Sep 2018 19:58:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 19 Sep 2018 19:58:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; 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; s= fm2; bh=tZLKY4qNDd4sTGFLTierd4IUXUIKnqFJOYuPoEjDVaQ=; b=2OkmaLlT wYuKitoY0og824QjM1Ck+ibVmgPQrMx9+qsdEMgkKg9ylwcHaqrgNQIqJxKYGER0 VKHoJjXcJ3YbQbflNJ++a/aKCmdyzyD9QmiJgsLejQFevA6s/pWNFz8W9J/yRuSH Teik2QokXLP4LXK2OIC4V8Qt7UTUpSo3Ru0plcuTq1Fyx0ynbxKweI1vtVXhMOzd KbwLZBEpL2XX9V4Z6BD69662eXmWN0AMrBWwkihjcEsmJerEgSbnfJPZRk9I7KFW e7ZY9VaHCnGHkvAlc0uX6m3ajjYGeCum/YbxtBaooC3dU7eN+dzNsJKB1K/hrXqG dGb/JACm7uePyg== 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-sender :x-me-sender:x-sasl-enc; s=fm3; bh=tZLKY4qNDd4sTGFLTierd4IUXUIKn qFJOYuPoEjDVaQ=; b=NYeuR5+d+J1ez8UjehoI9K+oztf8Cg0z7TZ381xyPmS0i 9DyRdH4XyBOz4O1pF7BxPIV53bkYhGtjs7sVGjhfdMLzKJHVvWfC0EwkXK9Mqww+ 37AuCBya2+fza46nEwul3KETncC7/GdXg7eOxHBm/zXmOp3/guLDDekalpLz/bYV 6mrpanutlENhjCWtCr5A3mGVToJZIHVEMhsI87aT9G6hYBFgmSuiozhGlnMr4GIY SYq5Jb40GAx0fy0OrEjLy5vpegBy41n4zV8f1VAea6ZCDs0R45v8V+sHoXn2a2T3 ND3anb0Sw22HiTVSplxYhAQobaZE/8ytVl1aMd9pA== X-ME-Proxy: X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 33219102D3; Wed, 19 Sep 2018 19:58:23 -0400 (EDT) Date: Thu, 20 Sep 2018 08:58:20 +0900 From: Michael Paquier To: Tom Lane Cc: Laurenz Albe , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi Message-ID: <20180919235820.GA1338@paquier.xyz> References: <3883.1537200836@sss.pgh.pa.us> <11148.1537227504@sss.pgh.pa.us> <20180918001143.GG31460@paquier.xyz> <20180918024227.GI31460@paquier.xyz> <23296.1537281909@sss.pgh.pa.us> <71bf47219037a5e3839748eb55e4fa175b58f523.camel@cybertec.at> <25361.1537285137@sss.pgh.pa.us> <20180919023211.GC1650@paquier.xyz> <26882.1537372501@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <26882.1537372501@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 19, 2018 at 11:55:01AM -0400, Tom Lane wrote: > I'm OK with this approach. I wonder though what happens if you take > away the "#ifdef FRONTEND" and just enforce that one or the other mode > is selected always. That would seem like a sensible solution rather > than a wart to me ... Thanks, I have pushed the solution from Laurenz to maintain pure compatibility. The origin of the failures reported by pg_dump actually comes from a mismatch with pg_hba.conf in the way users and/or databases are parsed. I am glad that we have tests for the full range of ASCII characters in TAP so as it is easy to detect regressions at early stages. We could try to manipulate more setmode calls like the one in miscinit.c so as authentication gets the right call. I am not sure of other side effects though... -- Michael --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlui4pwACgkQnvQgOdby QH38uhAAoWn9ggAAOhsO7miurgdRLiC149WDhcIwTg8dLviCu+92hvrqyLIK+BzX Bc/LDNq/kTYxiGF1VAcCLCKODx8ezwYVOStRBPh4UjBR/K1G/TNsV1J5DOz719Xp 2Sguk0LmD+wrfRsRz5ms6ggLf2O4/CLm71UOWqiTKkpyVPJWQsOcA7G2St0fjLsN cviNGl+FWIrxOYV18ZVR7LR9jNYkslBrXijeRpuxlj7f9ZNLrF13oqiqVL15GOtQ KmRb7ePYnNi2RxzVx7nHIR0PSFrteXi38JzVpdjp1rJ387seCNcDG69oun6puNfU zb50vl3exY47b/QDGHEZWryGT1eILj3XuyvwdITx3GVFBCtoJQBKFxVOU19TGlQz onmmG7FSB2w1/cmGcCkSKpo1QkjYicxu0Tj+Hg7yFCT86MYY44DxepmlC1iBGSEK rnG30g/4LQ50HkA2B0VPMDG+nqvkNXGsJoeHyryvilAnEBoAGg3qaYAcgkGYBssQ EAvjBQICEanGOlNcPahMr+HfyAoHuKVXJHRvROgTFqYn8DwkBIBoh3UyWh2bl4c5 MUA2AlPMImweZHjHs20g34Xs0Im9YcZLukKu7zN40/a3DJJfa5awg/VbvycZfAQf XhE9Lp45rs0QRNhF9fvgoZg60kbmOQAIX2iSg02ti3CFbY5/D0k= =FoLu -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--