| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Heath Lord <heath(dot)lord(at)crunchydata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REL_13_STABLE Windows 10 Regression Failures |
| Date: | 2020-11-11 15:25:51 |
| Message-ID: | 2494569.1605108351@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo(dot)santamaria(at)gmail(dot)com> writes:
> On Wed, Nov 11, 2020 at 2:32 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On 2020-11-09 12:18:34 -0500, Tom Lane wrote:
>>> Yeah, it seems like the error-recovery longjmp has suddenly broken;
>>> but why here? There's nothing unusual about this specific error case.
> This looks like a known issue in MinGW64 builds [1], which is derived from
> an also known issue in MSVC's handling of setjmp/longjmp [2].
> [1] https://sourceforge.net/p/mingw-w64/bugs/406/
> [2] https://docs.microsoft.com/en-us/cpp/cpp/using-setjmp-longjmp
Not sure I believe that. The trouble with diagnosing this as a generic
"setjmp is broken" situation is that then it's not very credible that the
regression tests got this far. As for [2], that's talking specifically
about longjmp not executing C++ destructors, which isn't an issue for us.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-11-11 16:14:39 | BUG #16710: Deprecated timezone |
| Previous Message | Peter Eisentraut | 2020-11-11 14:56:50 | Re: pg should ignore u+200b zero width space |