Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through
От | Jim C. Nasby |
---|---|
Тема | Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through |
Дата | |
Msg-id | 20051017214849.GY86144@pervasive.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Do all accesses to shared buffer
|
Список | 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 по дате отправления: