From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
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 00:05:12 -0400
Message-ID: <2522602.1622433912@sss.pgh.pa.us> (raw)
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>
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=hamerkop&dt=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
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: tgl@sss.pgh.pa.us, michael@paquier.xyz, 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: <2522602.1622433912@sss.pgh.pa.us>
* 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