| 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-06-07 14:38:03 |
| Message-ID: | 869606.1623076683@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:
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-06-07 14:40:27 | Re: Race condition in recovery? |
| Previous Message | Robert Haas | 2021-06-07 13:58:53 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |