Re: Missing CFI in hlCover()? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Missing CFI in hlCover()?
Date
Msg-id 459519.1595607709@sss.pgh.pa.us
Whole thread Raw
In response to Missing CFI in hlCover()?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Missing CFI in hlCover()?  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Mark unconditionally-safe implicit coercions as leakproof
Next
From: Robert Haas
Date:
Subject: Re: Making CASE error handling less surprising