Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Benjamin <davidben(at)google(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions
Date: 2024-11-29 18:36:21
Message-ID: 524949.1732905381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Benjamin <davidben(at)google(dot)com> writes:
> Thanks! I got asked about release branches, so I thought I'd pass it along:
> how do you all handle merges to release branches and would it make sense to
> merge this change? On the one hand, nothing is actively on fire yet, but
> the current setup does risk breakage if OpenSSL ever migrates BIO_s_socket
> to their new size_t-clean internals.

We theoretically could back-patch 6f782a2a1, as it doesn't appear to
introduce any ABI-breaking changes. (The new field in struct Port
could be an issue, but it looks like it fits into what was padding
space, so probably fine.) However, I'm not sure that it's attractive
to do so from a risk/benefit standpoint. That code's received only
minimal testing so far, and the problem it's fixing is as yet
hypothetical.

On balance I think I'd vote against a back-patch now. We could
reconsider next year once PG v18 has gotten a reasonable amount of
beta testing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2024-11-29 18:39:13 Re: UUID v7
Previous Message Andres Freund 2024-11-29 18:17:29 Re: Changing shared_buffers without restart