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

From Tom Lane
Subject Re: seawasp failing, maybe in glibc allocator
Date
Msg-id 1378908.1624111923@sss.pgh.pa.us
Whole thread Raw
In response to Re: seawasp failing, maybe in glibc allocator  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: seawasp failing, maybe in glibc allocator  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Sat, Jun 19, 2021 at 5:07 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> if (error != LLVMErrorSuccess)
>> LLVMOrcDisposeMaterializationUnit(mu);
>> 
>> +#if LLVM_VERSION_MAJOR > 12
>> +       for (int i = 0; i < LookupSetSize; i++)
>> +               LLVMOrcRetainSymbolStringPoolEntry(symbols[i].Name);
>> +#endif

> (Though, erm, that code probably either needs to move a bit further up
> or become conditional, considering the error case immediately above
> it, not sure which...)

Is a compile-time conditional really going to be reliable?  See nearby
arguments about compile-time vs run-time checks for libpq features.
It's not clear to me how tightly LLVM binds its headers and running
code.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error
Next
From: Mark Dilger
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error