From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Hubert Zhang <zhubert(at)vmware(dot)com>, tsunakawa(dot)takay(at)fujitsu(dot)com, pgsql-hackers(at)postgresql(dot)org, Andreas Seltenreich <seltenreich(at)gmx(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: Multiple hosts in connection string failed to failover in non-hot standby mode |
Date: | 2021-05-31 04:05:12 |
Message-ID: | 2522602.1622433912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Gibson (DB Administrator) | 2021-05-31 04:23:43 | Re: AWS forcing PG upgrade from v9.6 a disaster |
Previous Message | Bharath Rupireddy | 2021-05-31 04:01:24 | Re: Fdw batch insert error out when set batch_size > 65535 |