Re: REL_13_STABLE Windows 10 Regression Failures
От | Juan José Santamaría Flecha |
---|---|
Тема | Re: REL_13_STABLE Windows 10 Regression Failures |
Дата | |
Msg-id | CAC+AXB0+1=GEqxZt2LhkeR767aGLD2nu5hEA3QMsmWuw4xeLRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: REL_13_STABLE Windows 10 Regression Failures (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: REL_13_STABLE Windows 10 Regression Failures
|
Список | 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 по дате отправления: