Date: Mon, 31 May 2021 15:31:08 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Hubert Zhang <zhubert@vmware.com>,
	tsunakawa.takay@fujitsu.com, pgsql-hackers@postgresql.org,
	Andreas Seltenreich <seltenreich@gmx.de>,
	Bruce Momjian <bruce@momjian.us>
Subject: Re: Multiple hosts in connection string failed to failover in
 non-hot standby mode
Message-ID: <YLSCrAPVfxX3X8ap@paquier.xyz>
References: 
 <TYAPR01MB299012CAC510D2644AEC2246FE160@TYAPR01MB2990.jpnprd01.prod.outlook.com>
 <BN6PR05MB3492DFB2FF32B771172CC2F2C9170@BN6PR05MB3492.namprd05.prod.outlook.com>
 <229507.1610056206@sss.pgh.pa.us>
 <770711.1610318330@sss.pgh.pa.us>
 <20210506162651.GJ27406@telsasoft.com>
 <4170264.1620321747@sss.pgh.pa.us>
 <20210531012500.GP2082@telsasoft.com>
 <YLRDV0MqQnGRIo4c@paquier.xyz>
 <YLRZH6CWs9N6Pusy@paquier.xyz>
 <2522602.1622433912@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vlgQx4A1AKAL9xfR"
Content-Disposition: inline
In-Reply-To: <2522602.1622433912@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/YLSCrAPVfxX3X8ap%40paquier.xyz>
Precedence: bulk


--vlgQx4A1AKAL9xfR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 31, 2021 at 12:05:12AM -0400, Tom Lane wrote:
> Yeah, I was looking at that earlier today.  Evidently libpq is
> trying a GSS-encrypted connection, and that doesn't work, so
> it falls back to a regular connection where we get the expected
> error.  Probably all the connections in this test are hitting the
> GSS failure, but only the ones where the second attempt fails
> show a visible issue.

Yep.  This wastes cycles.

> What is not clear is why GSS is acting that way.  We wouldn't
> have tried a GSS connection unless pg_GSS_have_cred_cache
> succeeded ... so how come that worked but then gss_init_sec_context
> complained "Credential cache is empty"?
>=20
> My rough guess is that Windows has implemented the GSS APIs in
> such a way that what pg_GSS_have_cred_cache is testing isn't
> sufficient to tell whether a sane credential actually exists.
>=20
> Or there's something particularly weird about how hamerkop
> is set up.

I suspect that's just the way the upstream installation works with a
credentials cache created from the beginning, as I see the same
behavior and the same error on my own host for HEAD with a KRB5 server
set up once the upstream installation runs.  Leaving the specific
topic of this thread aside for one moment, would there be an argument
for just enforcing gssencmode=3Ddisable in this set of tests down to 12?
It is worth noting that the problem does not show up in 12 and 13 once
the compilation works, because we just mask the error there, but the
code path is still taken.

Another thing that strikes me as incorrect is that we don't unset
PGGSSENCMODE or PGGSSLIB in TestLib.pm.  Just noting it on the way..
--
Michael

--vlgQx4A1AKAL9xfR
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmC0gqwACgkQnvQgOdby
QH0STg/+JcjwwCYmmBZBtpPniHGb/OdGTns/1LsEjyepQv+4c2f8ilPoblj16wyJ
RogltwvVwKBRxGyHb8u30KDty0M/eMT++zZHpQ8V9uyTOM7G1f+ootlf32mREFLG
j/eGntMtTGtaNnQRXvX8fd/UjtCSRWyH3vqH5AMBqmSM3bIJ86iP9nLqUd3T07Dj
hgXHwtEW1rPJ7A0I2XtyOM+l78+Jl+1lqY6rSrQsL3RmJuBKVjF1moqidOjlj//D
6QHKdozcL8FgiU91Ln+rn7hBvuedwXJVFRRTncmN80jCAE238oJGCtrF07uCFHCJ
he5aK475/beR5NdFDI0EGTG3ZtLS+vxoYpBGbgEdGknz9hVsII+KWtTzgZ0+FmC9
h3DXn8b8pSsV3r6xfNqGwLtAg3b59w984yvOFN0BtvIo+CTTB1vPzCUeCovt91y6
ESklg6ohw19dvlce9oFFR3FOSeH8LbXMD1MKInuGQ0JKBnw4J47rNkz77a/XQfRh
zF+xuUilBJIfvqb4NaeeYO/FJPME6ENlNTjlxGx3oe286P6UjNNUIUWJVf2zUlM/
9flJKKcYnJfITJR5Prh+DTegJZra8DqknQQ/cOd+TL+YGkrcDUx+Rv/IY/xrn7VZ
ynLugP20wmnngFtyj5JrgOaE9TRJrwIkfwU9w0UduC8xbVRa/q0=
=+Lat
-----END PGP SIGNATURE-----

--vlgQx4A1AKAL9xfR--