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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Дата
Msg-id CA+hUKGKT2FDTmTXWtdwZ5Ps+Xg+Ewf+y_-bZvf_BSinqgxCDYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jan 5, 2023 at 11:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Ah, OK.  I had the impression from the way the code is laid out with a
wall between "PostgreSQL" bits and "vendored library" bits that we
might have some reason to want to keep that callback interface the
same (ie someone else is using this code and we want to stay in
sync?), but your reactions are a clue that maybe I imagined a
requirement that doesn't exist.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: wake up logical workers after ALTER SUBSCRIPTION