Re: jsonpath

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: jsonpath
Дата
Msg-id CAPpHfduP2ShBe3r80u0zsOGxRG1XRd4c7PTj-iPfmv4DzL2dyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: jsonpath  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: jsonpath  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: jsonpath
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: A separate table level option to control compression