Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, Noah Misch <noah@leadboat.com>,
Robert Haas <robertmhaas@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-04T22:55:43Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > Hm. Seems confusing for this to continue being called rcancelrequested() and > to be called via if(CANCEL_REQUESTED()), if we're not even documenting that > it's intended to be usable that way? Yeah. I'm not very happy with this line of development at all, because I think we are painting ourselves into a corner by not allowing code to detect whether a cancel is pending without having it happen immediately. (That is, I do not believe that backend/regex/ is the only code that will ever wish for that.) But if that is the direction we're going to go in, we should probably revise these APIs to make them less odd. I'm not sure why we'd keep the REG_CANCEL error code at all. > I think it might be nicer to create this below CacheMemoryContext? Meh ... CacheMemoryContext might not exist yet, especially for the use-cases in the login logic. regards, tom lane
Commits
-
Fix recovery conflict SIGUSR1 handling.
- 0da096d78e1e 17.0 landed
-
Redesign interrupt/cancel API for regex engine.
- db4f21e4a34b 16.0 landed
-
Update contrib/trgm_regexp's memory management.
- 6db75edb2ecb 16.0 landed
-
Update tsearch regex memory management.
- 4f51429dd7f1 16.0 landed
-
Use MemoryContext API for regex memory management.
- bea3d7e3831f 16.0 landed