From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Benjamin <davidben(at)google(dot)com>, 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 19:57:43 |
Message-ID: | 37DB2E05-503D-49EA-8B17-7B31C92F09AD@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 29 Nov 2024, at 19:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.
I agree with all of the above.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-11-29 20:17:54 | Re: UUID v7 |
Previous Message | Marcos Pegoraro | 2024-11-29 19:46:54 | Re: UUID v7 |