Обсуждение: 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