Re: global / super barriers (for checksums)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: global / super barriers (for checksums)
Date: 2019-07-19 17:18:57
Message-ID: 20190719171857.6zfvzvw66277te55@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-07-19 17:28:14 should there be a hard-limit on the number of transactions pending undo?
Previous Message Andres Freund 2019-07-19 17:12:57 Re: [RFC] Removing "magic" oids