From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Hubert Zhang <zhubert@vmware.com>
Cc: tsunakawa.takay@fujitsu.com, pgsql-hackers@postgresql.org, Andreas Seltenreich <seltenreich@gmx.de>
Cc: Bruce Momjian <bruce@momjian.us>
Subject: Re: Multiple hosts in connection string failed to failover in non-hot standby mode
Date: Mon, 31 May 2021 15:31:08 +0900
Message-ID: <YLSCrAPVfxX3X8ap@paquier.xyz> (raw)
In-Reply-To: <2522602.1622433912@sss.pgh.pa.us>
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>
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"?
>
> 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.
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=disable 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
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, pryzby@telsasoft.com, zhubert@vmware.com, seltenreich@gmx.de, bruce@momjian.us
Subject: Re: Multiple hosts in connection string failed to failover in non-hot standby mode
In-Reply-To: <YLSCrAPVfxX3X8ap@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox