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: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-08T00:14:33Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Apr 08, 2023 at 01:32:22AM +1200, Thomas Munro wrote:
>> I'm hoping to get just the regex changes in ASAP, and then take a
>> little bit longer on the recovery conflict patch itself (v6-0005) on
>> the basis that it's bugfix work and not subject to the feature freeze.

> Agreed.  It would be good to check with the RMT, but as long as that's
> not at the middle/end of the beta cycle I guess that's OK for this
> one, even if it is only for HEAD.

Right.  regex changes pass an eyeball check here.

			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.