On Mon, Sep 13, 2021 at 04:09:26PM -0400, Tom Lane wrote:
> I got around to looking at this issue today, and verified that only one
> place needs to be changed, as attached.
Thanks! This looks fine to me at quick glance.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> On Sun, May 30, 2021 at 08:25:00PM -0500, Justin Pryzby wrote:
>> ..But I think it's not useful to put details into errorMessage on success,
>> unless you're going to document that. It would never have occurred to me to
>> look there, or that it would even be safe.
> Ye
I wrote:
> Now I'm inclined to go back to the first-draft patch I had, which just
> dropped the first problematic test case, and added gssencmode=disable
> to the second one.
Done that way. If we figure out why the GSS code is acting strangely
on hamerkop, maybe this can be reverted --- but it se
Michael Paquier writes:
> On Wed, Jun 09, 2021 at 12:05:10PM -0400, Tom Lane wrote:
>> Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression,
> Using ecpg2_regression for the role goes a bit against the recent rule
> to not create any role not suffixed by "regress_" as part of
On Wed, Jun 09, 2021 at 12:05:10PM -0400, Tom Lane wrote:
> Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression,
> which matches the name of one of the databases used, allowing the test
> cases with defaulted database name to succeed. That gets rid of one of
> the problematic
I wrote:
> ... I'd be okay with dropping that test; or maybe we could
> fix things so that the default case succeeds?
Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression,
which matches the name of one of the databases used, allowing the test
cases with defaulted database name
Michael Paquier writes:
> On Tue, Jun 08, 2021 at 11:21:34AM -0400, Tom Lane wrote:
>> IIUC, what you are proposing to do is replace pgwin32_setenv with
>> src/port/setenv.c. I don't think that's an improvement. setenv.c
>> leaks memory on repeat calls, because it cannot know what
>> pgwin32_set
On Tue, Jun 08, 2021 at 11:21:34AM -0400, Tom Lane wrote:
> IIUC, what you are proposing to do is replace pgwin32_setenv with
> src/port/setenv.c. I don't think that's an improvement. setenv.c
> leaks memory on repeat calls, because it cannot know what
> pgwin32_setenv knows about how putenv work
Michael Paquier writes:
> Now, I also see that using pgwin32_setenv() instead of
> src/port/setenv.c causes cl to be confused once we update
> ecpg_regression.proj because it cannot find setenv(). Bringing the
> question, why is it necessary to have both setenv.c and
> pgwin32_setenv() on HEAD?
On Mon, Jun 07, 2021 at 10:38:03AM -0400, Tom Lane wrote:
> Hmm. We do include "-lpgcommon -lpgport" when building the ecpg test
> programs on Unix, so I'd assumed that the MSVC scripts did the same.
> Is there a good reason not to make them do so?
I was looking at that this morning, and yes we n
Michael Paquier writes:
> On Sun, Jun 06, 2021 at 05:27:49PM -0400, Tom Lane wrote:
>> So I took
>> a look at disabling GSSENC in these test cases to try to silence
>> hamerkop's test failure that way. Here's a proposed patch.
>> It relies on setenv() being available, but I think that's fine
>> b
On Sun, Jun 06, 2021 at 05:27:49PM -0400, Tom Lane wrote:
> It seems like nobody's terribly interested in figuring out why
> pg_GSS_have_cred_cache() is misbehaving on Windows.
I have been investigating that for a couple of hours in total, but
nothing to report yet.
> So I took
> a look at disabl
It seems like nobody's terribly interested in figuring out why
pg_GSS_have_cred_cache() is misbehaving on Windows. So I took
a look at disabling GSSENC in these test cases to try to silence
hamerkop's test failure that way. Here's a proposed patch.
It relies on setenv() being available, but I thi
On Mon, May 31, 2021 at 09:07:38PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>>> Agreed, that seems bogus.
>
>> There may be others, and I have not checked yet. I'd rather do a
>> backpatch for this part, would you agree?
>
> +1
Playing with all those variables and broken values here an
Michael Paquier writes:
>>> 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.
> There may be others, and I have not checked yet. I'd rather do a
> backpatch for this part, would
On Mon, May 31, 2021 at 09:36:20AM -0400, Tom Lane wrote:
> Interesting --- I was considering running such a test locally, but
> didn't get round to it yet.
Just to be clear, that's my Windows dev box.
> It seems like the ideal solution would be to make pg_GSS_have_cred_cache
> smarter, so that w
Michael Paquier 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 "Cr
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
Michael Paquier 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 a
On Mon, May 31, 2021 at 11:00:55AM +0900, Michael Paquier wrote:
> Yeah. On the contrary, it could be confusing if one sees an error
> message but there is nothing to worry about, because things are
> working in the scope of what the user wanted at connection time.
In my recent quest to look at G
On Sun, May 30, 2021 at 08:25:00PM -0500, Justin Pryzby wrote:
> ..But I think it's not useful to put details into errorMessage on success,
> unless you're going to document that. It would never have occurred to me to
> look there, or that it would even be safe.
Yeah. On the contrary, it could b
On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > 52a10224 broke sqlsmith, of all things.
>
> > It was using errmsg as a test of success, instead of checking if the
> > connection
> > result wasn't null:
>
> > conn = PQconnectdb(conninfo.c_str());
> >
> On 11 May 2021, at 09:29, Michael Paquier wrote:
> FWIW, I think that the case of getting some information about any
> failed connections while a connection has been successfully made
> within the scope of the connection string parameters provided by the
> user is rather thin, and I really feel
On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote:
> Hm. I'd debated whether to clear conn->errorMessage at the end of
> a successful connection sequence, and decided not to on the grounds
> that it might be interesting info (eg it could tell you why you
> ended up connected to server Y and
> On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote:
>> I'm curious though why it took this long for anyone to complain.
>> I'd supposed that people were running sqlsmith against HEAD on
>> a pretty regular basis.
Last time I ran it was November 27. I'm neglecting it on my spare time
and t
On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote:
> I'm curious though why it took this long for anyone to complain.
> I'd supposed that people were running sqlsmith against HEAD on
> a pretty regular basis.
I think it's also becase sqlsmith would need to run against the v14 *client*
libra
Justin Pryzby writes:
> 52a10224 broke sqlsmith, of all things.
> It was using errmsg as a test of success, instead of checking if the
> connection
> result wasn't null:
> conn = PQconnectdb(conninfo.c_str());
> char *errmsg = PQerrorMessage(conn);
> if (strlen(errmsg))
>
On Sun, Jan 10, 2021 at 05:38:50PM -0500, Tom Lane wrote:
> I wrote:
> > The problems that I see in this area are first that there's no
> > real standardization in libpq as to whether to append error messages
> > together or just flush preceding messages; and second that no effort
> > is made in mu
Hubert Zhang writes:
> As for patch 0004, find ':' after "could not connect to" may failed when
> error message like:
> "could not connect to host "localhost" (::1), port 12345: Connection
> refused", where p2 will point to "::1" instead of ": Connection refused". But
> since it's only used for
10:56 AM
To: Hubert Zhang
Cc: tsunakawa.ta...@fujitsu.com ;
pgsql-hack...@postgresql.org
Subject: Re: Multiple hosts in connection string failed to failover in non-hot
standby mode
I wrote:
> I feel pretty good about 0001: it might be committable as-is. 0002 is
> probably subject to bik
I wrote:
> The problems that I see in this area are first that there's no
> real standardization in libpq as to whether to append error messages
> together or just flush preceding messages; and second that no effort
> is made in multi-connection-attempt cases to separate the errors from
> different
Hubert Zhang writes:
> [ 0001-Enhance-libpq-to-support-multiple-host-for-non-hot-s.patch ]
I took a quick look at this. TBH, I'd just drop the first three hunks,
as they've got nothing to do with any failure mode that there's evidence
for in this thread or the prior one, and I'm afraid they're m
From: Hubert Zhang
> Hao Wu and I wrote a patch to fix this problem. Client side libpq should try
> another hosts in connection string when it is rejected by a non-hot standby,
> or the first host encounter some n/w problems during the libpq handshake.
Thank you. Please add it to the November
2020 5:30 PM
To: Hubert Zhang
Cc: pgsql-hack...@postgresql.org
Subject: RE: Multiple hosts in connection string failed to failover in non-hot
standby mode
Please send emails in text format. Your email was in HTML, and I changed this
reply to text format.
From: Hubert Zhang
> Lib
On Tue, Oct 27, 2020 at 07:14:14AM +, Hubert Zhang wrote:
> Libpq has supported to specify multiple hosts in connection string and enable
> auto failover when the previous PostgreSQL instance cannot be accessed.
> But when I tried to enable this feature for a non-hot standby, it cannot do
> t
Please send emails in text format. Your email was in HTML, and I changed this
reply to text format.
From: Hubert Zhang
> Libpq has supported to specify multiple hosts in connection string and enable
> auto failover when the previous PostgreSQL instance cannot be accessed.
> But when I tried
Hi hackers,
Libpq has supported to specify multiple hosts in connection string and enable
auto failover when the previous PostgreSQL instance cannot be accessed.
But when I tried to enable this feature for a non-hot standby, it cannot do the
failover with the following messages.
psql: error: co
37 matches
Mail list logo
