Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Дата
Msg-id 878yp8h8b3.fsf@stark.dyndns.tv
обсуждение исходный текст
Ответ на Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:

> Lee Kindness writes:
> 
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
> 
> The problem with this is that the automatic determination (in configure)
> whether there is a xxx_r()  version is, in general, fragile.  We cannot
> rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
> should be good enough.  Else, we'd be shipping claimed-to-be-thread-safe
> libraries that might trigger bugs that will be hard to track down.

Um. I don't think that's true. I mean, in theory it's true, but in practice
why would an OS have some *_r but have only non-thread-safe versions of
others?

The only OSes like that would be ones that were in the process of developing
thread-safe libraries and hadn't finished yet. Perhaps early versions of
Solaris or CVS snapshots of BSD? I don't know of any actual releases that
anyone would want to be running today.

Postgres doesn't need to work around problems like that. At worst it should
have a blacklist of OS versions that it knows not to even bother building a
threadsafe libpq for.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: massive quotes?
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Preliminary notes about hash index concurrency (long)