Re: problems on Solaris

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

In response to

Responses

Browse pgsql-hackers by date

  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