Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Date
Msg-id 309727.1606251594@sss.pgh.pa.us
Whole thread Raw
In response to Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 25 Nov 2020 at 04:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> walleye's been failing since this patchset went in:
>> I have no idea what to make of that, but it looks more like a compiler bug
>> than anything else.

> I wondered if #if !defined(__MINGW32__) && !defined(__MINGW64__) would
> be the correct fix for it... aka, just define the new
> pg_attribute_(hot|cold) macros to empty on MinGW.

I'd make any such fix as narrow as possible (ie MINGW64 only, based on
present evidence).  It'd be nice to have a compiler version upper bound
too, in the hopes that they'd fix it in future.  Maybe something like
"#if defined(__MINGW64__) && defined(__GNUC__) && __GNUC__ <= 8" ?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Alvaro Herrera
Date:
Subject: Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path