Re: Another regexp performance improvement: skip useless paren-captures - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Another regexp performance improvement: skip useless paren-captures
Date
Msg-id A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com
Whole thread Raw
In response to Re: Another regexp performance improvement: skip useless paren-captures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Another regexp performance improvement: skip useless paren-captures  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Another regexp performance improvement: skip useless paren-captures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

I can still trigger the old bug for which we thought we'd pushed a fix.  The test case below crashes on master
(e12694523e7e4482a052236f12d3d8b58be9a22c),and also on the fixed version "Make regexp engine's backref-related
compilationstate more bulletproof." (cb76fbd7ec87e44b3c53165d68dc2747f7e26a9a). 

Can you test if it crashes for you, too?  I'm not sure I see why this one fails when millions of others pass.

The backtrace is still complaining about regc_nfa.c:1265:

+select regexp_split_to_array('', '(?:((?:q+))){0}(\1){0,0}?*[^]');
+server closed the connection unexpectedly
+   This probably means the server terminated abnormally
+   before or while processing the request.
+connection to server was lost

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Next
From: Bruce Momjian
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE