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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Дата
Msg-id CA+hUKGJ=_2KUebSbabLLC3q+boqPxpKMWjaFa84_Zfm2xokzZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Jan 5, 2023 at 12:33 PM Andres Freund <andres@anarazel.de> wrote:
> What about using a version of errsave() that can save FATALs too? We could
> have something roughly like the ProcessInterrupts() in the proposed patch that
> is used from within rcancelrequested(). But instead of actually throwing the
> error, we'd just remember the to-be-thrown-later error, that the next
> "real" CFI would throw.

Right, I contemplated variations on that theme.  I'd be willing to
code something like that to kick the tyres, but it seems like it would
make back-patching more painful?  We're trying to fix bugs here...
Deciding to proceed with #6 (palloc) wouldn't mean we can't eventually
also implement two phase/soft CFI() when we have a potential user, so
I don't really get the painted-into-a-corner argument.  However, it's
all moot if the #6 isn't good enough on its own merits independent of
other hypothetical future users (eg if the per regex_t MemoryContext
overheads are considered too high and can't be tuned acceptably).



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Some compiling warnings
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Split index and table statistics into different types of stats