Horton

Re: global / super barriers (for checksums)

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Magnus Hagander <magnus@hagander.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2019-11-25T22:44:21Z
Lists: pgsql-hackers 
On Wed, Nov 13, 2019 at 12:26 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On the other hand, 0002 seems like it's pretty clearly a good idea. It
> makes a whole bunch of auxiliary processes use
> procsignal_sigusr1_handler() and those things all get called from
> AuxiliaryProcessMain(), which does ProcSignalInit(), and it seems like
> clearly the right idea that processes which register to participate in
> the procsignal mechanism should also register to get notified if they
> receive a procsignal. I think that the reason we haven't bothered with
> this up until now is because I think that it's presently impossible
> for any of the kind of procsignals that we have to get sent to any of
> those processes. But, global barriers would require us to do so, so it
> seems like it's time to tighten that up, and it doesn't really cost
> anything. So I propose to commit this part soon, unless somebody
> objects.

Done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Online enabling and disabling of data checksums

  2. Extend the ProcSignal mechanism to support barriers.

  3. Partially deduplicate interrupt handling for background processes.

  4. Use PostgresSigHupHandler in more places.

  5. Move interrupt-handling code into subroutines.

  6. Use procsignal_sigusr1_handler for auxiliary processes.