Re: seawasp failing, maybe in glibc allocator - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: seawasp failing, maybe in glibc allocator
Date
Msg-id CA+hUKGJpR0Vx6vd=7kkewvJYy0qrULHaCQz7y=owMBtXrSMjUA@mail.gmail.com
Whole thread Raw
In response to Re: seawasp failing, maybe in glibc allocator  (Andres Freund <andres@anarazel.de>)
Responses Re: seawasp failing, maybe in glibc allocator
List pgsql-hackers
On Sun, Jun 20, 2021 at 10:59 PM Andres Freund <andres@anarazel.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

Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members
Next
From: Tom Lane
Date:
Subject: Re: seawasp failing, maybe in glibc allocator