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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Дата
Msg-id CA+TgmoZMrmjyaxsA=ozXbRXAWWns4AtQ6HBCZHH=m1uPc+dR4Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Wed, Jun 15, 2022 at 1:51 AM Michael Paquier <michael@paquier.xyz> wrote:
> Handle is more consistent with the other types of interruptions in the
> SIGUSR1 handler, so the name proposed in the patch in not that
> confusing to me.  And so does Process, in spirit with
> ProcessProcSignalBarrier() and ProcessLogMemoryContextInterrupt().
> While on it, is postgres.c the best home for
> HandleRecoveryConflictInterrupt()?  That's a very generic file, for
> starters.  Not related to the actual bug, just asking.

Yeah, there's existing precedent for this kind of split in, for
example, HandleCatchupInterrupt() and ProcessCatchupInterrupt(). I
think the idea is that "process" is supposed to sound like the more
involved part of the operation, whereas "handle" is supposed to sound
like the initial response to the signal.

I'm not sure it's the clearest possible naming, but naming things is
hard, and this patch is apparently not inventing a new way to do it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: better page-level checksums
Следующее
От: Robert Haas
Дата:
Сообщение: Re: "buffer too small" or "path too long"?