From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: seawasp failing, maybe in glibc allocator |
Date: | 2021-06-21 10:23:25 |
Message-ID: | 20210621102325.jiwgl7idxmdcixv3@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-06-20 19:56:56 -0400, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Looking at their release schedule on https://llvm.org/, I see we have
> > a gamble to make. They currently plan to cut RC1 at the end of July,
> > and to release in late September (every second LLVM major release
> > coincides approximately with a PG major release). Option 1: wait
> > until we branch for 14, and then push this to master so that at least
> > seawasp can get back to looking for new problems, and then back-patch
> > only after they release (presumably in time for our November
> > releases). If their API change sticks, PostgreSQL crashes and gives
> > weird results with the initial release of LLVM 13 until our fix comes
> > out. Option 2: get ahead of their release and get this into 14 +
> > August back branch releases based on their current/RC behaviour. If
> > they decide to revert the change before the final release, we'll leak
> > symbol names because we hold an extra reference, until we can fix
> > that.
I think I'd vote for 2 or 2+ (backpatch immediately).
> If that's an accurate characterization of the tradeoff, I have little
> difficulty in voting for #2. A crash is strictly worse than a memory
> leak. Besides which, I've heard little indication that they might
> revert.
We might be able to get them to revert and put in a different API, but I
don't think it'd clearly be an improvement at this point.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-06-21 10:32:10 | Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values |
Previous Message | Greg Nancarrow | 2021-06-21 10:10:02 | Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values |