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
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 |