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
|
Список | 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 по дате отправления: