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: <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>
 <YLSCrAPVfxX3X8ap@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Mon, 31 May 2021 15:31:08 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2566985.1622468180.1@sss.pgh.pa.us>
Date: Mon, 31 May 2021 09:36:20 -0400
Message-ID: <2566986.1622468180@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2566986.1622468180%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Mon, May 31, 2021 at 12:05:12AM -0400, Tom Lane wrote:
>> 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"?

> 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.

Interesting --- I was considering running such a test locally, but
didn't get round to it yet.

> Leaving the specific
> topic of this thread aside for one moment, would there be an argument
> for just enforcing gssencmode=disable in this set of tests down to 12?

It seems like the ideal solution would be to make pg_GSS_have_cred_cache
smarter, so that we don't attempt a GSS connection cycle here.  But if
we can't, adding gssencmode=disable to these test cases is what I was
thinking about, too.

> 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..

Agreed, that seems bogus.

			regards, tom lane