Обсуждение: UnixWare 7.1.4 (and OpenServer) sigwait issue
Continuing http://archives.postgresql.org/pgsql-hackers/2009-01/msg01762.php Bruce Momjian wrote:>> Well, this helps explain why were are getting these problems reports> only now. How many hacks doyou have that we don't support, aside from> the threading one for HPUX?> Compiling threaded libpq on UnixWare fails on sigwait. I quickly setup a test for unixware 7.1.4. The only issue I found was with sigwait. Although unixware does have a 2arg POSIX.1c version, it requires setting _XOPEN_SOURCE and _POSIX_C_SOURCE in such a manner that breaks other things: (http://uw714doc.sco.com/en/man/html.3pthread/sigwait.3pthread.html). My solution was: 1. added the below to configure.in line 1620, same section as PGAC_FUNC_POSIX_SIGNALS checks. AC_MSG_CHECKING(for POSIX.1c sigwait) AC_TRY_COMPILE([#include <signal.h>], [sigwait((const sigset_t *)NULL, (int *)NULL)], [AC_DEFINE(HAVE_POSIX1C_SIGWAIT,1, [Define if the system includes a POSIX.1c sigwait]) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]) 2. Remove the sigwait prototype declaration from src/test/thread/thread_test.c. I do not know why it is forcing the 2 argversion of sigwait? Any insight would be helpful. Maybe it is for good reason. 3. Update fe-secure.c line 1337, the only place that uses sigwait, to the below: #ifdef HAVE_POSIX1C_SIGWAIT sigwait(&sigpipe_sigset, &signo); #else signo = sigwait(&sigpipe_sigset); #endif If these changes seemare acceptable, I will provide a formal patch. BTW, openserver has the same issue so this kills two birds with one stone. Not sure if openserver has other issues yet, test scheduled for Monday. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
I don't think anyone replied to your questions below so let me try. I am afraid this falls in the same category as the HP-UX patch, in that it is for threading on an older platform and is more for a single site rather than something where more users can benefit. It would be interesting if you could host a web page, perhaps on our wiki, that lists patches for older platforms so we don't lose this information and it might be helpful to use some day. --------------------------------------------------------------------------- Andrew Chernow wrote: > Continuing http://archives.postgresql.org/pgsql-hackers/2009-01/msg01762.php > > Bruce Momjian wrote: > > > > Well, this helps explain why were are getting these problems reports > > only now. How many hacks do you have that we don't support, aside from > > the threading one for HPUX? > > > > Compiling threaded libpq on UnixWare fails on sigwait. > > I quickly setup a test for unixware 7.1.4. The only issue I found was with > sigwait. Although unixware does have a 2arg POSIX.1c version, it requires > setting _XOPEN_SOURCE and _POSIX_C_SOURCE in such a manner that breaks other things: > > (http://uw714doc.sco.com/en/man/html.3pthread/sigwait.3pthread.html). > > My solution was: > > 1. added the below to configure.in line 1620, same section as > PGAC_FUNC_POSIX_SIGNALS checks. > > AC_MSG_CHECKING(for POSIX.1c sigwait) > AC_TRY_COMPILE([#include <signal.h>], > [sigwait((const sigset_t *)NULL, (int *)NULL)], > [AC_DEFINE(HAVE_POSIX1C_SIGWAIT, 1, > [Define if the system includes a POSIX.1c sigwait]) > AC_MSG_RESULT(yes)], > [AC_MSG_RESULT(no)]) > > 2. Remove the sigwait prototype declaration from src/test/thread/thread_test.c. > I do not know why it is forcing the 2 arg version of sigwait? Any insight > would be helpful. Maybe it is for good reason. > > 3. Update fe-secure.c line 1337, the only place that uses sigwait, to the below: > > #ifdef HAVE_POSIX1C_SIGWAIT > sigwait(&sigpipe_sigset, &signo); > #else > signo = sigwait(&sigpipe_sigset); > #endif > > If these changes seemare acceptable, I will provide a formal patch. BTW, > openserver has the same issue so this kills two birds with one stone. Not sure > if openserver has other issues yet, test scheduled for Monday. > > -- > Andrew Chernow > eSilo, LLC > every bit counts > http://www.esilo.com/ > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> I am afraid this falls in the same category as the HP-UX patch, in that > it is for threading on an older platform Really? It was released in 2004 (maintenance pack 4 released in June 2008). > It would be interesting if you could host a web page, perhaps on our > wiki, that lists patches for older platforms so we don't lose this > information and it might be helpful to use some day. > That sounds like an interesting idea. I was already considering putting it on the libpqtypes.esilo.com website. Maybe a better place would be on the pgwiki. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
Andrew Chernow wrote: > > > I am afraid this falls in the same category as the HP-UX patch, in that > > it is for threading on an older platform > > Really? It was released in 2004 (maintenance pack 4 released in June 2008). Oh, I didn't know that. We have had lots of problems with SCO/Unixware bugs in the past so there is no great love for keeping that platform going. Also, there is much threading API churn that we haven't been fond of trying to get everything working. It would also be nice if someone else said they wanted this to work. ;-) > > It would be interesting if you could host a web page, perhaps on our > > wiki, that lists patches for older platforms so we don't lose this > > information and it might be helpful to use some day. > > > > That sounds like an interesting idea. I was already considering putting it on > the libpqtypes.esilo.com website. Maybe a better place would be on the pgwiki. Yea, probably. It would help us gather interest and perhaps include them someday. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> going. Also, there is much threading API churn that we haven't been fond > of trying to get everything working. > The provided pthreads is 100% busted on unixware. I'd only recommend its use to someone I don't like :) This is one of several platforms that we use the GNU Pth library as a replacement. Providing a patch is only half the issue, one must use GNU Pth. > It would also be nice if someone else said they wanted this to work. ;-) > Yeah. Not sure how popular unixware is. We don't see it much, but we do see lots of openserver. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
Andrew Chernow wrote: > > going. Also, there is much threading API churn that we haven't been fond > > of trying to get everything working. > > > > The provided pthreads is 100% busted on unixware. I'd only recommend its use to > someone I don't like :) This is one of several platforms that we use the GNU > Pth library as a replacement. Providing a patch is only half the issue, one > must use GNU Pth. OK, so you are confirming my suspicions and leanings. This reinforces the idea of adding a wiki entry where these details can be documented. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +