Re: seawasp failing, maybe in glibc allocator

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: seawasp failing, maybe in glibc allocator
Дата
Msg-id 1587578.1624233416@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: seawasp failing, maybe in glibc allocator  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Thomas Munro <thomas.munro@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: seawasp failing, maybe in glibc allocator
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: seawasp failing, maybe in glibc allocator