Re: BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head

"Regina Obe" <lr(at)pcorp(dot)us> writes:
> The backtrace of that looks like this:

> #0 0x00007ffe76032136 in ntdll!RtlRaiseStatus ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> #1 0x00007ffe75f60bb3 in ntdll!RtlUnwindEx ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> #2 0x00007ffe74002eed in msvcrt!_setjmpex ()
> from C:\WINDOWS\System32\msvcrt.dll
> #3 0x00000000008da31a in pg_re_throw () at elog.c:1776
> #4 0x00000000008da19d in errfinish (filename=<optimized out>,
> filename(at)entry=0xa291a0 <BinarySignature+24> "copyto.c",
> lineno=lineno(at)entry=490,
> funcname=funcname(at)entry=0xa29980 <__func__.112127> "BeginCopyTo")
> at elog.c:589
...

> I'll go thru the other tests to see which ones are crashes and provide a bt
> of those too if you find it useful.
> Anyway at a glance they all seem to be on tests designed to throw an error.

It does look suspiciously like something is broken in our attempt to
longjmp back to the server's outermost loop. We had a similar report
last fall, also about MinGW:

https://www.postgresql.org/message-id/flat/CA%2BBEBhvHhM-Bn628pf-LsjqRh3Ang7qCSBG0Ga%2B7KwhGqrNUPw%40mail.gmail.com

and I don't think we ever figured out what was happening there either.

(FWIW, walleye's owners report that the failure goes away when they
change their compiler options to more debug-friendly settings. Hmm.)

regards, tom lane