Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
От | Alvaro Herrera |
---|---|
Тема | Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path |
Дата | |
Msg-id | 20201124210431.GA833@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path |
Список | pgsql-hackers |
On 2020-Nov-24, Tom Lane wrote: > 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" ? Apparently the bug was fixed days after it was reported, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048 but they haven't made a release containing the fix yet.
В списке pgsql-hackers по дате отправления: