Re: Lockless StrategyGetBuffer() clock sweep - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Lockless StrategyGetBuffer() clock sweep
Date
Msg-id CA+Tgmob=CK8ib6YqcfjG+oAYahXQFiH8ffk7M_dVhscDQvaBYQ@mail.gmail.com
Whole thread Raw
In response to Re: Lockless StrategyGetBuffer() clock sweep  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Lockless StrategyGetBuffer() clock sweep  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Dec 8, 2014 at 2:51 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-10-30 07:55:08 -0400, Robert Haas wrote:
>> On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> >> But if it is, then how about
>> >> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
>> >> and just checking the flag instead of checking bgwriterLatch itself?
>> >
>> > Yea, that'd be nicer. I didn't do it because it made the patch slightly
>> > more invasive... The complexity really is only needed because we're not
>> > guaranteed that 64bit reads are atomic. Although we actually can be
>> > sure, because there's no platform with nonatomic intptr_t reads - so
>> > 64bit platforms actually *do* have atomic 64bit reads/writes.
>> >
>> > So if we just have a integer 'setBgwriterLatch' somewhere we're good. We
>> > don't even need to take a lock to set it. Afaics the worst that can
>> > happen is that several processes set the latch...
>>
>> OK, that design is fine with me.
>
> There's a slight problem with this, namely restarts of bgwriter. If it
> crashes the reference to the relevant latch will currently be reset via
> StrategyNotifyBgWriter(). In reality that's not a problem because
> sizeof(void*) writes are always atomic, but currently we don't assume
> that. We'd sometimes write to a old latch, but that's harmless because
> they're never deallocated.
>
> So I can see several solutions right now:
> 1) Redefine our requirements so that aligned sizeof(void*) writes are
>    always atomic. That doesn't affect any currently supported platform
>    and won't ever affect any future platform either. E.g. linux has had
>    that requirement for a long time.
> 2) Use a explicitly defined latch for the bgworker instead of using the
>    PGPROC->procLatch. That way it never has to be reset and all
>    SetLatch()s will eventually go to the right process.
> 3) Continue requiring the spinlock when setting the latch.

Maybe you could store the pgprocno instead of the PROC *.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: tracking commit timestamps
Next
From: Robert Haas
Date:
Subject: Re: [v9.5] Custom Plan API