Daniel Gustafsson <dan...@yesql.se> writes:
> On 5 Dec 2019, at 15:50, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> What I'd like to know is whether not
>> realizing that SSL_clear_options is present causes any functional
>> issues that would justify back-patching a fix.
> ISTM that SSL_clear_options is required for turning on compression. Since
> compression was introduced in 1.0.0 and SSL_clear_options was turned into a
> function in 1.1.0, it affects 1.0.0, 1.0.1 and 1.0.2 with the latter two being
> quite heavily used. I'm not sure how common it is to enable compression, and
> especially how common it is post-CRIME, but since the option is there it seems
> silly for it not to work with highly common library versions. Removing the
> check only affects NetBSD 5, but breaking compilation in a stable release,
> even
> for a rare OS, is I assume/hope a no-no. So thats a +1 from me for back-
> patching a fix, while removing the check altogether in master.
Agreed that we should do something about this. However, our requirement
for 0.9.8 or newer has been there since v10 (cf. 593d4e47d). So I think
what we should do is
(1) Back-patch Michael's
0002-Remove-configure-checks-for-SSL_clear_options-in-Ope.patch
from the other thread [1] as far as v10.
(2) Use this patch in 9.4-9.6.
It'd be possible to also backpatch the other thread's
0001-Remove-configure-checks-for-SSL_get_current_compress.patch
as far as v10, but I'm less excited about that -- it'd just save
a few configure cycles, no?
regards, tom lane
[1] https://www.postgresql.org/message-id/20191205083252.GE5064%40paquier.xyz
