Re: pgsql: Get rid of backtracking in jsonpath_scan.l

On 3/26/19 12:36 PM, Andrew Dunstan wrote:
> On 3/26/19 11:22 AM, Alvaro Herrera wrote:
>> On 2019-Mar-26, Andrew Dunstan wrote:
>>
>>> On 3/25/19 8:44 AM, Alexander Korotkov wrote:
>>>> Get rid of backtracking in jsonpath_scan.l
>>>>
>>>> Non-backtracking flex parsers work faster than backtracking ones. So, this
>>>> commit gets rid of backtracking in jsonpath_scan.l. That required explicit
>>>> handling of some cases as well as manual backtracking for some cases. More
>>>> regression tests for numerics are added.
>>> jacana appears to be having trouble with this:
>>>
>>>
>>> 2019-03-26 00:49:02.208 EDT [5c99ae9e.20cc:6] LOG: server process (PID 8368) was terminated by exception 0xC0000028
>> 0xC0000028 is STATUS_BAD_STACK, per
>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
>> Not sure how credible/useful a stack trace is going to be.
>>
>
> Right, and getting stack traces isn't easy in any case. There is a
> gadget from Google that is supposed to trap exceptions and produce a
> stack trace on the fly in mingw. I'm going to take a look at it,
> although loading it might be ... interesting.
>
>

Still working on this. However, I have another data point. On a shiny
new Msys2/WS2019 system (on AWS/EC2) this does not reproduce, even
though jacana seems to be producing it quite reliably.

To get the backtrace gadget working I think I'm going to have to add
some code like:

#if defined(WIN32) && defined(LOAD_BACKTRACE)

    LoadLibraryA("backtrace.dll");

#endif

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services