Re: global / super barriers (for checksums) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: global / super barriers (for checksums)
Date
Msg-id 20190719171857.6zfvzvw66277te55@alap3.anarazel.de
Whole thread Raw
In response to Re: global / super barriers (for checksums)  (Magnus Hagander <magnus@hagander.net>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC] Removing "magic" oids
Next
From: Robert Haas
Date:
Subject: should there be a hard-limit on the number of transactions pending undo?