Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-07 Thread Michael Paquier
On Mon, Jan 06, 2020 at 05:18:02PM +1030, Andrew Dunstan wrote: > I was going to upgrade it when I could migrate the OS of the host machine > to CentOS 8. However, last time I looked some things about Centos 8 (e.g. > EPEL) were not mature enough. In any case, to do that requires my physical > pre

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-06 Thread Tom Lane
Michael Paquier writes: > On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote: >> I propose the attached, which removes the unnecessary entries >> and puts full control of the IPv4/IPv6 decision in one place >> (well, two places). The test will still always connect over IPv4, >> but at least

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-06 Thread Michael Paquier
On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote: > I propose the attached, which removes the unnecessary entries > and puts full control of the IPv4/IPv6 decision in one place > (well, two places). The test will still always connect over IPv4, > but at least there's now a clear route to c

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-06 Thread Michael Paquier
On Mon, Jan 06, 2020 at 03:08:25PM -0500, Tom Lane wrote: > I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are > not out of the woods there: > > * prairiedog required 6:46 to run the ssl test [1], compared to 3:24 > in its last run with 0.9.8x. Why so much slower? I have seen the te

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-06 Thread Tom Lane
I wrote: > * gaur fell over in the ssl test [2]. I had not asked it to run that > test before, so this may well be a pre-existing issue not something > new with the version change. It looks like something in that test > is assuming that we have IPv6 support, which maybe it shouldn't be, > even in

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-06 Thread Tom Lane
I wrote: > You'll probably see failures from some of my dinosaurs too. > I've not yet switched them over to using newer OpenSSL, > but will do so tomorrow or so. I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are not out of the woods there: * prairiedog required 6:46 to run the ssl t

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-05 Thread Andrew Dunstan
On Mon, Jan 6, 2020 at 3:50 PM Michael Paquier wrote: > On Mon, Jan 06, 2020 at 12:06:30AM -0500, Tom Lane wrote: > > As I recall, we'd already decided that nightjar needs to be EOL'd > > because that version of FreeBSD has nonatomic file rename [1]. > > Ah, indeed. I forgot this discussion, and

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-05 Thread Michael Paquier
On Mon, Jan 06, 2020 at 12:06:30AM -0500, Tom Lane wrote: > As I recall, we'd already decided that nightjar needs to be EOL'd > because that version of FreeBSD has nonatomic file rename [1]. Ah, indeed. I forgot this discussion, and that was not long ago. > You'll probably see failures from some

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-05 Thread Michael Paquier
On Mon, Jan 06, 2020 at 01:58:58PM +0900, Michael Paquier wrote: > So the buildfarm is not that bad, I have spotted one failure from > nightjar: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2020-01-06%2003%3A54%3A10 > > /pgbuild/root/HEAD/pgsql.build/../pgsql/src/interface

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-05 Thread Tom Lane
Michael Paquier writes: > On Mon, Jan 06, 2020 at 03:53:08AM +, Michael Paquier wrote: >> Remove support for OpenSSL 0.9.8 and 1.0.0 > So the buildfarm is not that bad, I have spotted one failure from > nightjar: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2020-01-06

Re: pgsql: Remove support for OpenSSL 0.9.8 and 1.0.0

2020-01-05 Thread Michael Paquier
On Mon, Jan 06, 2020 at 03:53:08AM +, Michael Paquier wrote: > Remove support for OpenSSL 0.9.8 and 1.0.0 > > Support is out of scope from all the major vendors for these versions > (for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1), > and it created some extra maintenance