Re: global / super barriers (for checksums)

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Magnus Hagander <magnus@hagander.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2019-07-19T17:18:57Z
Lists: pgsql-hackers
Hi,

On 2019-07-10 15:31:11 +0200, Magnus Hagander wrote:
> In re-reading this, I notice there are a lot of references to Intterrupt
> (with two t). I'm guessing this is just a spelling error, and not something
> that actually conveys some meaning?

Just a spelling error. I think I wrote the patch in a night after
pgconf.eu, to allow you to quickly make progress :P


> Can you elaborate on what you mean with:
> +       /* XXX: need a more principled approach here */

> Is that the thing you refer to above about "checksum internals"?

I think I didn't actually mean "checksum" but instead "checkpoint".  It
does bother me that we have an operation as long-running as BufferSync()
commonly is, without a proper way to accept event.  There's a hack for
doing something similar-ish in CheckpointWriteDelay(), for absorbing
fsync requests, but it doesn't trigger for checkpoints not done in
checkpointer, nor is it really extensible.


> Also in checking we figured it'd be nice to have a wait event for this,
> since a process can potentially get stuck in an infinite loop waiting for
> some other process if it's misbehaving. Kind of like the attached?

Yea, that makes sense.

Greetings,

Andres Freund



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.