Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through
Date
Msg-id 20051017214849.GY86144@pervasive.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Do all accesses to shared buffer
List pgsql-hackers
On Wed, Oct 12, 2005 at 10:46:14PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Does any of this need to be backpatched?
> 
> No --- we didn't have any per-buffer spinlocks before 8.1.
> 
> It's possible that at some point we'll need to start thinking about
> applying volatile-pointer coding rules to data structures protected by
> LWLocks.  This could only become an issue if the compiler (a) inlines
> LWLockAcquire/Release, and (b) tries to rearrange loads and stores
> around the LWLock code.  I would like to think that the latter is
> impossible even with inlining, principally because the compiler can't
> ignore the kernel calls that may occur within the LWLock routines;
> those should be treated as external function calls and hence sequence
> points, no matter how aggressive the compiler gets.  But we'll see.

Sorry if I'm just confused here, but don't LWLocks protect data
structures susceptible to corruption? And if that's the case don't we
need to be sure that the compiler can't optimize around them? Or will
this only result in things like buffers not getting un-pinned?
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: A costing analysis tool
Next
From: Simon Riggs
Date:
Subject: Re: Seeing context switch storm with 10/13 snapshot of