| From: | Pedro Gimeno <pgsql-004(at)personal(dot)formauri(dot)es> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Sandro Santilli <strk(at)keybit(dot)net>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: uninterruptable regexp_replace in 9.2 and 9.3 |
| Date: | 2014-03-02 13:07:29 |
| Message-ID: | 53132D11.2010305@personal.formauri.es |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Tom Lane wrote, On 2014-03-02 05:38:
> The performance problem we're looking at comes directly from the
> backtracking that's done to ensure that we detect a match in case the
> pattern has this sort of pathological behavior.
It is my understanding that the bug reported by the OP is not a
performance problem, but PostgreSQL's failure to interrupt the
processing if it takes too long, when statement_timeout is set.
If it's not possible to interrupt it, then maybe an approach similar to
PHP's backtracking limit could be implemented.
I'm not familiar at all with PostgreSQL's code, but I wonder if adding a
CHECK_FOR_INTERRUPTS every sensible number of backtracks could solve the
original bug.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haribabu Kommi | 2014-03-02 23:25:32 | Re: BUG #9370: PostgreSQL Service Unexpectedly closing in SERVER Computer |
| Previous Message | Tom Lane | 2014-03-02 04:38:38 | Re: uninterruptable regexp_replace in 9.2 and 9.3 |