Re: REL_13_STABLE Windows 10 Regression Failures - Mailing list pgsql-bugs

From Juan José Santamaría Flecha
Subject Re: REL_13_STABLE Windows 10 Regression Failures
Date
Msg-id CAC+AXB0+1=GEqxZt2LhkeR767aGLD2nu5hEA3QMsmWuw4xeLRg@mail.gmail.com
Whole thread Raw
In response to Re: REL_13_STABLE Windows 10 Regression Failures  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: REL_13_STABLE Windows 10 Regression Failures
List pgsql-bugs

On Wed, Nov 11, 2020 at 2:32 AM Andres Freund <andres@anarazel.de> wrote:
High,

On 2020-11-09 12:18:34 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Hmm, line 202 is the ereport in this test:
>
> >         if (!IsA(expr, ColumnRef))
> >             ereport(ERROR,
> >                     (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> >                      errmsg("only simple column references are allowed in CREATE STATISTICS")));
>
> > Not sure why that gives rise to the upper parts of the stack there.
>
> Yeah, it seems like the error-recovery longjmp has suddenly broken;
> but why here?  There's nothing unusual about this specific error case.

Perhaps PG_exception_stack got corrupted somehow? An oversized write to
a neighboring var?

Not sure if that works on mingw, but building with address sanitizer /
asan might be informative.

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].


Regards,

Juan José Santamaría Flecha

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #16707: Memory leak
Next
From: Kurt Roeckx
Date:
Subject: Re: BUG #16707: Memory leak