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
-
Online enabling and disabling of data checksums
- f19c0eccae96 19 (unreleased) landed
-
Extend the ProcSignal mechanism to support barriers.
- 16a4e4aecd47 13.0 landed
-
Partially deduplicate interrupt handling for background processes.
- 7dbfea3c455e 13.0 landed
-
Use PostgresSigHupHandler in more places.
- 1e53fe0e70f6 13.0 landed
-
Move interrupt-handling code into subroutines.
- 5910d6c7e311 13.0 landed
-
Use procsignal_sigusr1_handler for auxiliary processes.
- 0d3c3aae3366 13.0 landed