On Wed, Oct 12, 2005 at 10:46:14PM -0400, Tom Lane wrote:
> Bruce Momjian 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
On Wed, Oct 12, 2005 at 11:49:47PM -0400, Tom Lane wrote:
> That would certainly be better if possible, but AFAIK it's not.
> (Perhaps there is a gcc-specific hack, but certainly not one that's
> portable to all compilers. "volatile" is the only tool the C standard
> gives us.)
Indeed. The linux
Neil Conway <[EMAIL PROTECTED]> writes:
> Another way to fix the problem would be to have S_LOCK() and S_UNLOCK()
> force $CC to not rearrange loads and stores by themselves, without
> relying upon volatile pointers.
That would certainly be better if possible, but AFAIK it's not.
(Perhaps there is
Bruce Momjian 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
Does any of this need to be backpatched?
---
Tom Lane wrote:
> Log Message:
> ---
> Do all accesses to shared buffer headers through volatile-qualified
> pointers, to ensure that compilers won't rearrange accesses to
