Re: seawasp failing, maybe in glibc allocator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-20 23:56:56
Message-ID: 1587578.1624233416@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-06-21 01:23:34 Re: seawasp failing, maybe in glibc allocator
Previous Message Thomas Munro 2021-06-20 23:45:12 Re: seawasp failing, maybe in glibc allocator