Re: problems on Solaris

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: problems on Solaris
Дата
Msg-id 20150530230918.GA30287@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: problems on Solaris  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: problems on Solaris  (Robert Haas <robertmhaas@gmail.com>)
Re: problems on Solaris  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [CORE] postpone next week's release
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [CORE] postpone next week's release