From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org> |
Subject: | Re: problems on Solaris |
Date: | 2015-05-30 23:09:18 |
Message-ID: | 20150530230918.GA30287@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2015-05-31 00:38:29 | Re: [CORE] postpone next week's release |
Previous Message | David Steele | 2015-05-30 22:48:06 | Re: [CORE] postpone next week's release |