On 2015-05-31 08:00:44 -0400, Robert Haas wrote: > 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?
It's not yet entirely clear what that'd be unfortunately. Maybe we could use waitpid(PostmasterPid, status, WNOHANG) - afaics that should work. > > 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. On second thought they're unfortunately not entirely suitable. While we've had used semaphores in signal indirectly for a long while (e.g. deadlock detector, sinval code etc), they're formally not guaranteed to be signal safe. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
