Re: Missing CFI in hlCover()?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Missing CFI in hlCover()?
Дата
Msg-id 459519.1595607709@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Missing CFI in hlCover()?  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Missing CFI in hlCover()?  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> I'm looking into an issue that we're seeing on the PG archives server
> with runaway queries that don't seem to ever want to end- and ignore
> signals.

> This is PG11, 11.8-1.pgdg100+1 specifically on Debian/buster and what
> we're seeing is the loop in hlCover() (wparser_def.c:2071 to 2093) is
> lasting an awful long time without any CFI call.  It's possible the CFI
> call should actually go elsewhere, but the complete lack of any CFI in
> wparser_def.c or tsvector_op.c seems a bit concerning.

> I'm suspicious there's something else going on here that's causing this
> to take a long time but I don't have any smoking gun as yet.

Hm.  I'd vote for a CFI within the recursion in TS_execute(), if there's
not one there yet.  Maybe hlFirstIndex needs one too --- if there are
a lot of words in the query, maybe that could be slow?  Did you pin the
blame down any more precisely than hlCover?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Mark unconditionally-safe implicit coercions as leakproof
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Making CASE error handling less surprising