| От | Pedro Gimeno |
|---|---|
| Тема | Re: uninterruptable regexp_replace in 9.2 and 9.3 |
| Дата | |
| Msg-id | 53132D11.2010305@personal.formauri.es обсуждение исходный текст |
| Ответ на | Re: uninterruptable regexp_replace in 9.2 and 9.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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.
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера