Re: Multiple hosts in connection string failed to failover in non-hot standby mode - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Multiple hosts in connection string failed to failover in non-hot standby mode
Date
Msg-id 869606.1623076683@sss.pgh.pa.us
Whole thread Raw
In response to Re: Multiple hosts in connection string failed to failover in non-hot standby mode  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Multiple hosts in connection string failed to failover in non-hot standby mode  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> 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
>> because we link the ECPG test programs with libpgport.

> No, that's not it.  The compilation of the tests happens when
> triggering the tests as of ecpgcheck() in vcregress.pl so I think that
> this is going to fail.  This requires at least the addition of a
> reference to libpgport in ecpg_regression.proj, perhaps more.

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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Next
From: Robert Haas
Date:
Subject: Re: Race condition in recovery?