Re: seawasp failing, maybe in glibc allocator

On Sun, Jun 20, 2021 at 10:59 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think this should be part of the earlier loop? Once
> LLVMOrcAbsoluteSymbols() is called that owns the reference, so there
> doesn't seem to be a reason to increase the refcount only later?

Right, that makes sense. Here's a patch like that.

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.

For the last round of changes[1], there was a similar when-to-act
question, but that was a doesn't-compile-anymore API change, whereas
this is a silent demons-might-fly-out-of-your-nose API change.

[1] https://www.postgresql.org/message-id/flat/20201016011244.pmyvr3ee2gbzplq4%40alap3.anarazel.de