Re: jsonpath - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: jsonpath
Date
Msg-id CAPpHfduP2ShBe3r80u0zsOGxRG1XRd4c7PTj-iPfmv4DzL2dyQ@mail.gmail.com
Whole thread Raw
In response to Re: jsonpath  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonpath
List pgsql-hackers
On Sun, Apr 7, 2019 at 2:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> > Thus, contents of unused function makes test fail or pass.  So far, it
> > looks like a compiler bug.  Any thoughts?
>
> Yeah :-(.  The fact that we've not seen a similar failure on any other
> machines points in that direction, too.  Maybe it's some other aspect
> of the machine's toolchain, like flex or bison, but that's not that
> much different from our standpoint.
>
> There's a lot of stuff I don't especially like about jsonpath_scan,
> for instance I think the "init" arguments to resizeString etc are
> a pretty error-prone and unmaintainable way to do things.  But
> I don't see anything that looks like it'd be a portability hazard
> that would explain this.
>
> I still have a nagging feeling that there's a wild store somewhere
> in here, but I don't know how to find it based on the limited
> evidence we've got.

Yeah, it might be not because compiler error.  It might depend on
memory layout.  So existence of extra function changes memory layout
and, in turn, causes an error.  I will try to disassemble
jsonpath_scan.o and see whether content of yyparse2 influences
assembly of other functions.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: jsonpath
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: A separate table level option to control compression