Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Date
Msg-id CA+TgmoZMrmjyaxsA=ozXbRXAWWns4AtQ6HBCZHH=m1uPc+dR4Q@mail.gmail.com
Whole thread Raw
In response to Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Thomas Munro <thomas.munro@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: better page-level checksums
Next
From: Robert Haas
Date:
Subject: Re: "buffer too small" or "path too long"?