On Sat, May 30, 2015 at 7:09 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
