Re: problems on Solaris - Mailing list pgsql-hackers

From Andres Freund
Subject Re: problems on Solaris
Date
Msg-id 20150530230918.GA30287@alap3.anarazel.de
Whole thread Raw
In response to Re: problems on Solaris  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: problems on Solaris  (Robert Haas <robertmhaas@gmail.com>)
Re: problems on Solaris  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

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.

If people agree with that way forward, I'll go through the
platforms. The biggest one missing is probably solaris with sun's
compiler.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [CORE] postpone next week's release
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [CORE] postpone next week's release