From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: buffer README is out of date |
Date: | 2016-01-02 02:58:59 |
Message-ID: | 20160102025859.GA2953987@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 01, 2015 at 12:33:26AM -0500, Jim Nasby wrote:
> On 8/29/15 5:52 PM, Jeff Janes wrote:
> >If 2 other backends have a pin, only the last one to drop it should do
> >the waking. I don't see a way they could both try to do the waking, the
> >interlock on the buffer header seems to prevent that. But if it did,
> >that would just be another way you could have a spurious wake-up, which
> >can already happen for other reasons. I don't think the spurious wake
> >up needs to be documented in the higher level README file.
>
> My concern is someone will read too much into "signal will occur ... count
> to 1" and think there's no other ways to be woken up. I realize I'm being
> pedantic here, but given the nasty race condition bugs we've had lately
> maybe it's warranted.
Fair concern. I'm not too worried in this instance, because I can't think of
a choice the caller would make differently based on such a misunderstanding.
Precise wakeup conditions are not really part of the LockBufferForCleanup()
API contract[1]. The submission seems to move this README in the right
direction, so I committed it with some changes:
1. s/clean up/cleanup/
2. remove patch-added trailing whitespace
3. re-add to the first sentence a citation of rule #5
4. say that recovery can use LockBufferForCleanup(); heap_xlog_clean() does so
[1] If there's more to improve, it might be to move finer implementation
details out of the README and into code comments.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-01-02 03:10:24 | Re: [PATCH] Refactoring of LWLock tranches |
Previous Message | Noah Misch | 2016-01-02 00:55:42 | Re: Fwd: Core dump with nested CREATE TEMP TABLE |