From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
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
In-reply-to: <YLRZH6CWs9N6Pusy@paquier.xyz>
References: 
 <BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com>
 <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>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Mon, 31 May 2021 12:33:51 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2522601.1622433912.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 31 May 2021 00:05:12 -0400
Message-ID: <2522602.1622433912@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2522602.1622433912%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> In my recent quest to look at GSSAPI builds on Windows, I have bumped
> into another failure that's related to this thread.  hamerkop
> summarizes the situation here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dhamerkop&dt=3D=
2021-05-29%2010%3A15%3A42
> There are two failures like this one as errorMessage piles up on
> failures, as of connect/test5:
> -[NO_PID]: ECPGconnect: connection to server failed: FATAL:  database
>  "regress_ecpg_user2" does not exist
> +[NO_PID]: ECPGconnect: connection to server failed: could not
>  initiate GSSAPI security context: Unspecified GSS failure.  Minor
>  code may provide more information: Credential cache is empty
> +connection to server failed: FATAL:  database "regress_ecpg_user2"
>  does not exist =


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.

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"?

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.

Or there's something particularly weird about how hamerkop
is set up.

			regards, tom lane