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
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 |