On Sat, May 30, 2015 at 7:09 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-05-27 21:23:34 -0400, Robert Haas wrote:
>> > Oh wow, that's bad, and could explain a couple of the problems we're
>> > seing. One possible way to fix is to replace the sequence with if
>> > (!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has to be a barrier,
>> > even if the lock isn't free - which e.g. isn't the case for PowerPC's
>> > implementation :(
>>
>> Another possibility is to make the fallback barrier implementation a
>> system call, like maybe kill(PostmasterPid, 0).
>
> It's not necessarily true that all system calls are effective
> barriers. I'm e.g. doubtful that kill(..., 0) is one as it only performs
> local error checking. It might be that the process existance check
> includes a lock that's sufficient, but I would not like to rely on
> it. Sending an actual signal probably would be, but has the potential of
> disrupting postmaster progress.
So pick a better system call?
> I think we should just bite the bullet and require a barrier
> implementation for all architectures that have spinlock support. That
> should be fairly straightforward, even though distinctly unpleasurable,
> exercise. And then use semaphores (PGSemaphoreUnlock();PGSemaphoreLock()
> doesn't have the issue that spinlocks have) for --disable-spinlock
> platforms.
Like maybe this.
> If people agree with that way forward, I'll go through the
> platforms. The biggest one missing is probably solaris with sun's
> compiler.
Certainly, having real barriers everywhere would be great.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company