Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Date
Msg-id 2624973.1658877772@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
List 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



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Skip partition tuple routing with constant partition key
Next
From: Jacob Champion
Date:
Subject: Re: [Commitfest 2022-07] Patch Triage: Waiting on Author