Обсуждение: Thread safety

Can someone remind me why we have --enable-thread-safety? As opposed  
to it being default and having --disable-thread-safety.

/Magnus

Magnus Hagander wrote:
> Can someone remind me why we have --enable-thread-safety? As opposed to 
> it being default and having --disable-thread-safety.

I don't have any numbers or a roster to support this, but I suppose that 
thread-safety is not supported on some platforms.  So either we'd have 
to have diverging defaults or annoy those unsupported platforms with a 
mandatory switch.  The situation is quite similar in my view to the 
integer datetimes switch: we need a very high level of platform support 
before turning this on by default.

(I suppose there was initially also some general uncertainty about the 
maturity of thread things, but I think we can consider that satisfied by 
now.)

Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Can someone remind me why we have --enable-thread-safety? As opposed to 
>> it being default and having --disable-thread-safety.
>
> I don't have any numbers or a roster to support this, but I suppose that  
> thread-safety is not supported on some platforms.  So either we'd have  
> to have diverging defaults or annoy those unsupported platforms with a  
> mandatory switch.

We could try switching it for a day and see what happens to the
buildfarm ... that would give us an idea of how many platforms are not
prepared.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 27 nov 2008, at 13.00, Alvaro Herrera <alvherre@commandprompt.com>  
wrote:

> Peter Eisentraut wrote:
>> Magnus Hagander wrote:
>>> Can someone remind me why we have --enable-thread-safety? As  
>>> opposed to
>>> it being default and having --disable-thread-safety.
>>
>> I don't have any numbers or a roster to support this, but I suppose  
>> that
>> thread-safety is not supported on some platforms.  So either we'd  
>> have
>> to have diverging defaults or annoy those unsupported platforms  
>> with a
>> mandatory switch.
>
> We could try switching it for a day and see what happens to the
> buildfarm ... that would give us an idea of how many platforms are not
> prepared.
>
+1.

It would be very good to have it ok by default if we cab, and that  
seems luke a good way to see if it's reasonable...

/Magnus

Magnus Hagander wrote:
> On 27 nov 2008, at 13.00, Alvaro Herrera <alvherre@commandprompt.com> 
> wrote:
> 
>> Peter Eisentraut wrote:
>>> Magnus Hagander wrote:
>>>> Can someone remind me why we have --enable-thread-safety? As opposed to
>>>> it being default and having --disable-thread-safety.
>>>
>>> I don't have any numbers or a roster to support this, but I suppose that
>>> thread-safety is not supported on some platforms.  So either we'd have
>>> to have diverging defaults or annoy those unsupported platforms with a
>>> mandatory switch.
>>
>> We could try switching it for a day and see what happens to the
>> buildfarm ... that would give us an idea of how many platforms are not
>> prepared.
>>
> +1.
> 
> It would be very good to have it ok by default if we cab, and that seems 
> luke a good way to see if it's reasonable...
> 
> /Magnus
> 

It would probably be useful to nail down the supported platforms, have a list 
somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco, etc...

I ran into a few --enable-thread-safety problems, Magnus fixed the cygwin build 
already.  hpux 10.20 and solaris 2.5.1 were both broken.  Sounds like there is 
no interest in supporting hpux 10.20, not sure about solaris 2.5.1 realeased in 
1996.  I only discovered this trying to build libpqtypes, which requires libpq, 
on our internal build farm.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow napsal(a):

> 
> It would probably be useful to nail down the supported platforms, have a 
> list somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco, 
> etc...
> 
> I ran into a few --enable-thread-safety problems, Magnus fixed the 
> cygwin build already.  hpux 10.20 and solaris 2.5.1 were both broken.  
> Sounds like there is no interest in supporting hpux 10.20, not sure 
> about solaris 2.5.1 realeased in 1996.  

I don't think so that there is interest to fix it for solaris 2.5.1. Everything 
older than Solaris 8 is not officially supported (exclude timezone updates which 
are available for old systems) and Solaris 8 is in EOL mode.

Anyway solaris 2.5.1 runs only on old HW and I don't see any benefit to run new 
PostgreSQL version on hardware with small harddisk and memory.
    Zdenek