Thread: pg_config.h.win32 missing a set of flags from pg_config.h.in addedin v11 development

Hi all,

While reviewing the MSVC code, I have noticed that pg_config.h.win32 is
forgetting about a couple of flags defined in pg_config.h.in for v11
development.  Forgetting some of them is problematic, and here are the
ones I spotted:
- HAVE_LDAP_INITIALIZE
- HAVE_X509_GET_SIGNATURE_NID
- HAVE_SSL_CLEAR_OPTIONS

HAVE_X509_GET_SIGNATURE_NID is something I worked on for the SCRAM
channel binding, and not having it means that tls-server-end-point is
never supported on Windows.  What we need to do in this case is to
extend the MSVC scripts so as "openssl version" is run once and we parse
the version of OpenSSL from it.  If the version is newer than 1.0.2 then
the function can be used.

For HAVE_LDAP_INITIALIZE, it seems to me that we could get rid of the
ldap_sslinit part, but I have not studied this close enough to reach a
conclusion.

HAVE_SSL_CLEAR_OPTIONS means that sslcompression is not turned off by
default on Windows, which does not look like a good idea to me.

We could treat each issue separately, but the fact that we need to parse
the function string of openssl and/or openldap to do decision-making for
the MSVC script is common to all those issues.

Thanks,
--
Michael

On 29/05/18 17:15, Michael Paquier wrote:
> Hi all,
> 
> While reviewing the MSVC code, I have noticed that pg_config.h.win32 is
> forgetting about a couple of flags defined in pg_config.h.in for v11
> development.  Forgetting some of them is problematic, and here are the
> ones I spotted:
> - HAVE_LDAP_INITIALIZE
> - HAVE_X509_GET_SIGNATURE_NID
> - HAVE_SSL_CLEAR_OPTIONS
> 
> HAVE_X509_GET_SIGNATURE_NID is something I worked on for the SCRAM
> channel binding, and not having it means that tls-server-end-point is
> never supported on Windows.  What we need to do in this case is to
> extend the MSVC scripts so as "openssl version" is run once and we parse
> the version of OpenSSL from it.  If the version is newer than 1.0.2 then
> the function can be used.
> 
> For HAVE_LDAP_INITIALIZE, it seems to me that we could get rid of the
> ldap_sslinit part, but I have not studied this close enough to reach a
> conclusion.
> 
> HAVE_SSL_CLEAR_OPTIONS means that sslcompression is not turned off by
> default on Windows, which does not look like a good idea to me.
> 
> We could treat each issue separately, but the fact that we need to parse
> the function string of openssl and/or openldap to do decision-making for
> the MSVC script is common to all those issues.

I wouldn't be too sorry to just bump our minimum requirements for 
Windows, in v11. Assuming that recent-enough versions of OpenLSAP and 
OpenSSL are readily available on Windows. I think on Windows, you 
typically bundle the .dlls with the PostgreSQL binaries, so it would be 
natural to bundle the latest available libraries. And in the unlikely 
case that you'd want to use older ones, you could still modify 
pg_config.h.win32 manually.

But yeah, clearly those are missing from pg_config.h.win32 at the 
moment. It's not actually clear to me, when that file is (supposed to 
be) updated. Are you supposed to remember to update it, whenever you 
update pg_config.h.in? Or does someone update it with the results from 
some canonical MinGW buildfarm member before the release?

- Heikki

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> But yeah, clearly those are missing from pg_config.h.win32 at the 
> moment. It's not actually clear to me, when that file is (supposed to 
> be) updated. Are you supposed to remember to update it, whenever you 
> update pg_config.h.in? Or does someone update it with the results from 
> some canonical MinGW buildfarm member before the release?

AFAIK you have to update it manually; I've never seen anyone attempt
to rebuild it as per your second hypothesis.  There are bits of it
that configure definitely could not produce.

            regards, tom lane

On Sat, Jun 02, 2018 at 01:19:41PM -0400, Heikki Linnakangas wrote:
> I wouldn't be too sorry to just bump our minimum requirements for Windows,
> in v11. Assuming that recent-enough versions of OpenLSAP and OpenSSL are
> readily available on Windows.

s/OpenLSAP/OpenLDAP/.

It may be better to look at what the installers of EDB do then for this
purpose...  I don't have a Windows VM at hand now to install or
decompress this MSI, but my guess is that they use the LTS version of
1.0.2.

> I think on Windows, you typically bundle the
> .dlls with the PostgreSQL binaries, so it would be natural to bundle the
> latest available libraries.

Any sane Windows build would link to its dependent DLLs dynamically,
meaning that you usually need a copy of the DLLs in both bin/ and lib/
as libpq also needs to be able to load them and those need to be on the
same path as the library loaded (My Windows-bundling skills in this area
are far from being top-notch, but I got bitten by such things in the
past.)

> And in the unlikely case that you'd want to use
> older ones, you could still modify pg_config.h.win32 manually.

That makes the life of installer maintainers a bit harder than necessary
though.  One idea to simplify things could be to introduce an extra,
optional file whose contents are copied at the bottom of pg_config.h
automatically.  I am not sure that this is worth the pain, just
mentioning the possibility.
--
Michael

On Sat, Jun 02, 2018 at 01:24:41PM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> But yeah, clearly those are missing from pg_config.h.win32 at the
>> moment. It's not actually clear to me, when that file is (supposed to
>> be) updated. Are you supposed to remember to update it, whenever you
>> update pg_config.h.in? Or does someone update it with the results from
>> some canonical MinGW buildfarm member before the release?
>
> AFAIK you have to update it manually; I've never seen anyone attempt
> to rebuild it as per your second hypothesis.  There are bits of it
> that configure definitely could not produce.

c9e1ad7f for example, which is the last thing I could come up with.
Navigating through the logs of the buildfarm, it is actually not really
easy to find out which version of OpenSSL a build is using at compile
time.  Perhaps we would want first to report this information?
SSLeay_version is here for configure, while we could use a call to
"openssl version" for the MSVC scripts.

Actually, it seems that to me that SSL_OP_NO_COMPRESSION should also be
added..  Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the
minimal version of OpenSSL supported to 1.0.2, which is something I
would not feel much sorry about either like Heikki, as I have heard of
many vendors maintaining OpenSSL past versions on Linux, but not yet on
Windows.  It is easy to be wrong when it comes to any company policies
though.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> Navigating through the logs of the buildfarm, it is actually not really
> easy to find out which version of OpenSSL a build is using at compile
> time.  Perhaps we would want first to report this information?

+1 if we can figure a way to do it.  ISTR having looked for a way
and not found a good one.  The obvious answer is "ssh -V", but that
could report a library version that's different from what we're
linking to --- and indeed *would*, on several of my buildfarm
animals, because I point them to the appropriate openssl version with
--with-includes and --with-libs, neither of which touch PATH.

> ... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the
> minimal version of OpenSSL supported to 1.0.2, which is something I
> would not feel much sorry about either like Heikki, as I have heard of
> many vendors maintaining OpenSSL past versions on Linux, but not yet on
> Windows.  It is easy to be wrong when it comes to any company policies
> though.

I have assorted pet dinosaurs using 0.9.8x or 0.9.8y, but I'm not
sure that any of those still represent credible real-world cases.
More concerning is that RHEL6 is on 1.0.1e:

$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

That's definitely still a live platform.

            regards, tom lane

On 02/06/18 17:09, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> ... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the
>> minimal version of OpenSSL supported to 1.0.2, which is something I
>> would not feel much sorry about either like Heikki, as I have heard of
>> many vendors maintaining OpenSSL past versions on Linux, but not yet on
>> Windows.  It is easy to be wrong when it comes to any company policies
>> though.
> 
> I have assorted pet dinosaurs using 0.9.8x or 0.9.8y, but I'm not
> sure that any of those still represent credible real-world cases.
> More concerning is that RHEL6 is on 1.0.1e:

I was only thinking of requiring 1.0.2 on Windows. On other platforms, 
the configure tests work fine, and there's no problem supporting older 
versions. You just won't get tls-server-end-point channel binding 
support on older versions.

- Heikki

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 02/06/18 17:09, Tom Lane wrote:
>> More concerning is that RHEL6 is on 1.0.1e:

> I was only thinking of requiring 1.0.2 on Windows.

Ah.  Personally, I don't care about that case, but maybe somebody
else wants to speak for it?

            regards, tom lane

On Sat, Jun 02, 2018 at 05:20:57PM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 02/06/18 17:09, Tom Lane wrote:
>>> More concerning is that RHEL6 is on 1.0.1e:
>
>> I was only thinking of requiring 1.0.2 on Windows.
>
> Ah.  Personally, I don't care about that case, but maybe somebody
> else wants to speak for it?

That's what I meant as well.  Cutting the minimal OpenSSL version on
Linux would not come I think without complains so the requirements are
way higher.  I know of companies compiling and running benchmarks of
PostgreSQL on past RHEL and SUSE versions, linking to what's locally
available for simplicity.

A script which reports the version of OpenSSL should be simple enough
for MSVC.  And I am ready to bet that at least hamerkop is not using
OpenSSL 1.0.2, so a simple switch would most likely cause the buildfarm
to go red.  I am attaching in CC the maintainers of the Windows animals
so as they can comment.
--
Michael

> On Jun 3, 2018, at 4:29 AM, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Sat, Jun 02, 2018 at 05:20:57PM -0400, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>> On 02/06/18 17:09, Tom Lane wrote:
>>>> More concerning is that RHEL6 is on 1.0.1e:
>> 
>>> I was only thinking of requiring 1.0.2 on Windows.
>> 
>> Ah.  Personally, I don't care about that case, but maybe somebody
>> else wants to speak for it?
> 
> That's what I meant as well.  Cutting the minimal OpenSSL version on
> Linux would not come I think without complains so the requirements are
> way higher.  I know of companies compiling and running benchmarks of
> PostgreSQL on past RHEL and SUSE versions, linking to what's locally
> available for simplicity.
> 
> A script which reports the version of OpenSSL should be simple enough
> for MSVC.  And I am ready to bet that at least hamerkop is not using
> OpenSSL 1.0.2, so a simple switch would most likely cause the buildfarm
> to go red.  I am attaching in CC the maintainers of the Windows animals
> so as they can comment.

Wanted to check in and see if any of the Windows maintainers had thoughts
on this issue so we can continue to move it forward.

Thanks!

Jonathan

*On 2018-06-12 16:21, Jonathan S. Katz wrote:

>> On Jun 3, 2018, at 4:29 AM, Michael Paquier <michael@paquier.xyz> wrote:

>> A script which reports the version of OpenSSL should be simple enough
>> for MSVC.  And I am ready to bet that at least hamerkop is not using
>> OpenSSL 1.0.2, so a simple switch would most likely cause the buildfarm
>> to go red.  I am attaching in CC the maintainers of the Windows animals
>> so as they can comment.
> 
> Wanted to check in and see if any of the Windows maintainers had thoughts
> on this issue so we can continue to move it forward.

I can't contribute much; mine all build without OpenSSL anyway.

If I enable it in the future, it will be with libraries from vcpkg [1], 
and they are at 1.0.2o now and unlikely to go backwards.

[1] https://github.com/Microsoft/vcpkg/

-- 
Christian

On 06/12/2018 10:40 AM, Christian Ullrich wrote:
> *On 2018-06-12 16:21, Jonathan S. Katz wrote:
>
>>> On Jun 3, 2018, at 4:29 AM, Michael Paquier <michael@paquier.xyz> 
>>> wrote:
>
>>> A script which reports the version of OpenSSL should be simple enough
>>> for MSVC.  And I am ready to bet that at least hamerkop is not using
>>> OpenSSL 1.0.2, so a simple switch would most likely cause the buildfarm
>>> to go red.  I am attaching in CC the maintainers of the Windows animals
>>> so as they can comment.
>>
>> Wanted to check in and see if any of the Windows maintainers had 
>> thoughts
>> on this issue so we can continue to move it forward.
>
> I can't contribute much; mine all build without OpenSSL anyway.
>
> If I enable it in the future, it will be with libraries from vcpkg 
> [1], and they are at 1.0.2o now and unlikely to go backwards.
>
> [1] https://github.com/Microsoft/vcpkg/
>


Oh, nice, I will have to look into vcpkg. (This could well help in other 
contexts, too)

meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on 
1.0.2d and jacana (Mingw) doesn't build with openssl.

I will look at upgrading bowerbird ASAP.

cheers

andrew

On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
>
>
>
>
> meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on 
> 1.0.2d and jacana (Mingw) doesn't build with openssl.
>
> I will look at upgrading bowerbird ASAP.
>



Well, that crashed and burned. What versions of openssl are we supporting?

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Jun 12, 2018 at 04:51:59PM -0400, Andrew Dunstan wrote:
> On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
>> meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on
>> 1.0.2d and jacana (Mingw) doesn't build with openssl.
>>
>> I will look at upgrading bowerbird ASAP.
>
> Well, that crashed and burned. What versions of openssl are we supporting?

What kind of failures are you seeing?  I just compiled Postgres two days
ago with MSVC and OpenSSL 1.0.2o (oldest version with a Windows
installer I could find), and that was able to compile.  On HEAD, OpenSSL
should be supported down to 0.9.8.  This thread discusses about whether
we want to enforce HAVE_X509_GET_SIGNATURE_NID unconditionally or not,
as it is disabled now.  Even if the code is linked to 1.0.2 and the flag
is not set, then the code should be able to compile.
--
Michael

On Wed, Jun 13, 2018 at 09:07:20AM +0900, Michael Paquier wrote:
> What kind of failures are you seeing?  I just compiled Postgres two days
> ago with MSVC and OpenSSL 1.0.2o (oldest version with a Windows
> installer I could find), and that was able to compile.  On HEAD, OpenSSL
> should be supported down to 0.9.8.  This thread discusses about whether
> we want to enforce HAVE_X509_GET_SIGNATURE_NID unconditionally or not,
> as it is disabled now.  Even if the code is linked to 1.0.2 and the flag
> is not set, then the code should be able to compile.

So, I was looking at this part this morning, and I would suggest the
attached, which enables HAVE_X509_GET_SIGNATURE_NID and
HAVE_SSL_CLEAR_OPTIONS, raising the bar to have at least OpenSSL 1.0.2
on Windows (that's the minimum version easily findable when it comes to
MSI installers anyway these days).  I have checked that the code is able
to compile correctly as well.

HAVE_LDAP_INITIALIZE is added in the list, but this is disabled as I
could not test it.  It could always be possible to revisit that later.
Thomas, what do you think?

Thoughts?
--
Michael

On Wed, Jun 13, 2018 at 2:06 PM, Michael Paquier <michael@paquier.xyz> wrote:
> HAVE_LDAP_INITIALIZE is added in the list, but this is disabled as I
> could not test it.  It could always be possible to revisit that later.
> Thomas, what do you think?

It should be disabled on Windows, as you have it.

ldap_initialize() is a non-standard extension that provides a way to
use "ldaps" with OpenLDAP, but we don't even support using OpenLDAP on
Windows.  We know how to use Win32's non-standard extension
ldap_sslinit() instead if WIN32 is defined.

The reason we have a configure test is because ancient OpenLDAP as
shipped with ancient macOS and RHEL5 (present in our build farm) don't
have the function, and commercial LDAP API implementations that ship
with big iron Unices probably don't have it either.  It's not in
"ldapext-ldap-c-api-05.txt", which seems to be the last known version
of the eternally drafty standard.  Effectively, we'll fall back to
ldap_init() and disallow "ldaps" unless you have a fairly recent
OpenLDAP or Windows (I suspect that covers > 99% of users).

-- 
Thomas Munro
http://www.enterprisedb.com

On Wed, Jun 13, 2018 at 02:35:23PM +1200, Thomas Munro wrote:
> It should be disabled on Windows, as you have it.
>
> ldap_initialize() is a non-standard extension that provides a way to
> use "ldaps" with OpenLDAP, but we don't even support using OpenLDAP on
> Windows.  We know how to use Win32's non-standard extension
> ldap_sslinit() instead if WIN32 is defined.

Ah, OK.  I did not follow closely enough the thread about ldaps
myself. Thanks for the confirmation.
--
Michael

On 06/12/2018 08:07 PM, Michael Paquier wrote:
> On Tue, Jun 12, 2018 at 04:51:59PM -0400, Andrew Dunstan wrote:
>> On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
>>> meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on
>>> 1.0.2d and jacana (Mingw) doesn't build with openssl.
>>>
>>> I will look at upgrading bowerbird ASAP.
>> Well, that crashed and burned. What versions of openssl are we supporting?
> What kind of failures are you seeing?  I just compiled Postgres two days
> ago with MSVC and OpenSSL 1.0.2o (oldest version with a Windows
> installer I could find), and that was able to compile.  On HEAD, OpenSSL
> should be supported down to 0.9.8.  This thread discusses about whether
> we want to enforce HAVE_X509_GET_SIGNATURE_NID unconditionally or not,
> as it is disabled now.  Even if the code is linked to 1.0.2 and the flag
> is not set, then the code should be able to compile.



I installed 1.1.0h and got errors you can see on the buildfarm. I've now 
installed 1.0.2o and everything is good.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Jun 13, 2018 at 08:55:46PM -0400, Andrew Dunstan wrote:
> I installed 1.1.0h and got errors you can see on the buildfarm. I've now
> installed 1.0.2o and everything is good.

Good thing you tested that.  I have just used the LTS 1.0.2 for my
tests.  And there are a couple of problems here.

HAVE_BIO_GET_DATA is neither defined nor enforced in pg_config.h.win32,
and BIO_get_data has been introduced in 1.1.0, so that explains the
failures as you would need to add it in the config files.  I imagine
that most folks packaging Postgres on Windows simply rely on 1.0.2 (I
do!) which is why we have not seen reports of those failures...

A second failure is related to HAVE_BIO_METH_NEW, with all routine sets
like BIO_meth_set_write & co new as of OpenSSL 1.1.0.  The configure
check uses BIO_meth_new().

A third problem is related to HAVE_ASN1_STRING_GET0_DATA, but I don't
see a complain in the buildfarm logs, which is interesting, but that's
already present in pg_config.h.win32.

A fourth problem is with HAVE_OPENSSL_INIT_SSL, which is missing in
pg_config.h.win32.

We claim support for OpenSSL 1.1.0 down to 9.4 per bb132cdd, so I think
that we should document all those flags even in back-branches.  Thoughts
of people here?

For now, I would suggest to keep a track of HAVE_BIO_GET_DATA,
HAVE_BIO_METH_NEW and others in pg_config.h.win32 but mark them as
undef.  Anybody shipping Windows stuff also likely patch lightly the
MSVC scripts (I do for some paths!), so they could always enforce those
flags if building with OpenSSL 1.1.0...  Documenting them is really
important as well.  So attached is an updated patch which should be
applied on HEAD to close the gap and close this open item with all the
gaps mentioned in the commit message.  I'd like to document (but
disable!) as well the OpenSSL 1.1.0 flags down to 9.4 as that's where we
claim support of this version as bb132cd missed the shot.  This would
break Windows MSVC builds linking to OpenSSL 1.0.1 or older, so the
buildfarm will likely turn red here or there.

Thoughts?
--
Michael

On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
> Thoughts?

Okay, this is still an open item.  Are there any objections to the
previous patch applied on master and the addition of the following
undefined flags to pg_config.h.win32 for back-branches?  Here is the
list of flags which I think should be added but disabled for consistency
with the rest and compatibility with OpenSSL 1.1.0:
HAVE_ASN1_STRING_GET0_DATA
HAVE_BIO_GET_DATA
HAVE_BIO_METH_NEW
HAVE_OPENSSL_INIT_SSL
--
Michael

On 06/17/2018 08:15 AM, Michael Paquier wrote:
> On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
>> Thoughts?
> Okay, this is still an open item.  Are there any objections to the
> previous patch applied on master and the addition of the following
> undefined flags to pg_config.h.win32 for back-branches?  Here is the
> list of flags which I think should be added but disabled for consistency
> with the rest and compatibility with OpenSSL 1.1.0:
> HAVE_ASN1_STRING_GET0_DATA
> HAVE_BIO_GET_DATA
> HAVE_BIO_METH_NEW
> HAVE_OPENSSL_INIT_SSL



Looks OK.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
>> Okay, this is still an open item.  Are there any objections to the
>> previous patch applied on master and the addition of the following
>> undefined flags to pg_config.h.win32 for back-branches?  Here is the
>> list of flags which I think should be added but disabled for consistency
>> with the rest and compatibility with OpenSSL 1.1.0:
>> HAVE_ASN1_STRING_GET0_DATA
>> HAVE_BIO_GET_DATA
>> HAVE_BIO_METH_NEW
>> HAVE_OPENSSL_INIT_SSL

> Looks OK.

If we're just leaving them undefined, isn't this purely cosmetic?
At least, that was what I understood to be the reasoning for leaving
such symbols out of pg_config.h.win32 in the past.

I'm on board with making things more consistent in HEAD, but not sure
I see any need for back-patching.

            regards, tom lane

On Sun, Jun 17, 2018 at 10:57:16AM -0400, Tom Lane wrote:
> If we're just leaving them undefined, isn't this purely cosmetic?
> At least, that was what I understood to be the reasoning for leaving
> such symbols out of pg_config.h.win32 in the past.
>
> I'm on board with making things more consistent in HEAD, but not sure
> I see any need for back-patching.

I think that it is also important to give to those flags some
visibility so as packagers can more easily find what to switch on/off
when they come across compilation failures with a given version of
OpenSSL, so that's also a matter of documenting things.  You are right
that as the number of people doing packaging on Windows for Postgres can
perhaps be counted with the fingers of both hands, that may not be worth
bothering.  I maintain such stuff by the way, so this counts as one
finger up.

As there is visibly a consensus for HEAD, for now I propose to just
process with the previous patch on only the master branch then.  This
will address the open item.  Any objections to that?
--
Michael

On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
> As there is visibly a consensus for HEAD, for now I propose to just
> process with the previous patch on only the master branch then.  This
> will address the open item.  Any objections to that?

As there is a consensus at least on this part, I have just pushed the
patch to only HEAD.  I'll notify buildfarm members which see failures in
case those link to OpenSSL 1.0.1 or older.
--
Michael

On Tue, Jun 19, 2018 at 09:11:20AM +0900, Michael Paquier wrote:
> On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
> > As there is visibly a consensus for HEAD, for now I propose to just
> > process with the previous patch on only the master branch then.  This
> > will address the open item.  Any objections to that?
>
> As there is a consensus at least on this part, I have just pushed the
> patch to only HEAD.  I'll notify buildfarm members which see failures in
> case those link to OpenSSL 1.0.1 or older.

Andrew, bowerbird is complaining with what looks like a library loading
issue with initdb:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=bowerbird&dt=2018-06-19%2001%3A08%3A30&stg=check
pg_regress: initdb failed
Examine G:/prog/bf/root/HEAD/pgsql.build/src/test/regress/log/initdb.log
for the reason.

In my own environment I have a copy of ssleay32.dll and libeay32.dll in
c:\Windows\System32 so as that I don't get any complaints when running
regression tests.  Is your environment using something specific?
--
Michael

On 06/18/2018 11:13 PM, Michael Paquier wrote:
> On Tue, Jun 19, 2018 at 09:11:20AM +0900, Michael Paquier wrote:
>> On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
>>> As there is visibly a consensus for HEAD, for now I propose to just
>>> process with the previous patch on only the master branch then.  This
>>> will address the open item.  Any objections to that?
>> As there is a consensus at least on this part, I have just pushed the
>> patch to only HEAD.  I'll notify buildfarm members which see failures in
>> case those link to OpenSSL 1.0.1 or older.
> Andrew, bowerbird is complaining with what looks like a library loading
> issue with initdb:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=bowerbird&dt=2018-06-19%2001%3A08%3A30&stg=check
> pg_regress: initdb failed
> Examine G:/prog/bf/root/HEAD/pgsql.build/src/test/regress/log/initdb.log
> for the reason.
>
> In my own environment I have a copy of ssleay32.dll and libeay32.dll in
> c:\Windows\System32 so as that I don't get any complaints when running
> regression tests.  Is your environment using something specific?


I have adjusted the PATH setting - it should be fixed on the next run.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Jun 19, 2018 at 12:01:39AM -0400, Andrew Dunstan wrote:
>> In my own environment I have a copy of ssleay32.dll and libeay32.dll in
>> c:\Windows\System32 so as that I don't get any complaints when running
>> regression tests.  Is your environment using something specific?
>
> I have adjusted the PATH setting - it should be fixed on the next run.

Thanks!
--
Michael

Hi Andrew,

On Tue, Jun 19, 2018 at 01:25:58PM +0900, Michael Paquier wrote:
> On Tue, Jun 19, 2018 at 12:01:39AM -0400, Andrew Dunstan wrote:
>>> In my own environment I have a copy of ssleay32.dll and libeay32.dll in
>>> c:\Windows\System32 so as that I don't get any complaints when running
>>> regression tests.  Is your environment using something specific?
>>
>> I have adjusted the PATH setting - it should be fixed on the next run.
>
> Thanks!

lorikeet has also complained after the patch got in and turned green at
the follow-up run:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2018-06-19%2008%3A28%3A23
Was there a PATH issue for this machine as well?
--
Michael