Horton

Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-07-26T23:22:52Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@gmail.com> writes:
> ... The regular expression machinery is capable of
> consuming a lot of CPU, and does CANCEL_REQUESTED(nfa->v->re)
> frequently to avoid getting stuck.  With the patch as it stands, that
> would never be true.

Surely that can't be too hard to fix.  We might have to refactor
the code around QueryCancelPending a little bit so that callers
can ask "do we need a query cancel now?" without actually triggering
a longjmp ... but why would that be problematic?

			regards, tom lane

Commits

  1. Fix recovery conflict SIGUSR1 handling.

  2. Redesign interrupt/cancel API for regex engine.

  3. Update contrib/trgm_regexp's memory management.

  4. Update tsearch regex memory management.

  5. Use MemoryContext API for regex memory management.