Re: psql bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql bug
Date
Msg-id 17378.1337658242@sss.pgh.pa.us
Whole thread Raw
In response to Re: psql bug  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
>> Seems system() call cleanups sigaction state on FreeBSD.

> The root of problem is a threading library. In FreeBSD there are two versions of 
> sigaction() (system() and others) depending on thread enabled. libpq library is 
> compiled  by default with -pthread switch but psql is linked without that.
> This mixed linkage is a reason why system() call for external program loses 
> signal handler.

> Next, configure script correctly sets PTHREAD_* variables but PTHREAD_LIBS is 
> not used for psql linking.

> What is the best way to fix that? I suggest to add PTHREAD_LIBS to linking psql 
> at least. Although, suppose, it could be a reason for other cryptic bugs.

We could probably "fix" this by adding something like this to
Makefile.freebsd:

libpq += $(PTHREAD_LIBS)

However, the more I think about this, the more I think it is a FreeBSD
bug and the right solution is to complain loudly to the maintainers of
that platform.  The above hack might fix things for programs we ship as
part of Postgres, but what of other programs using libpq?  It cannot be
rational to expect that if libpq is linked to libpthread, then every
program that links to libpq must also be explicitly linked to
libpthread.  FreeBSD's linker is broken and they need to fix it, or
else they need to fix libpthread to be less invasive.

(Another reason for thinking this is that surely we'd have heard about
it before if this behavior were of long standing.  My money is on a
fairly recently introduced bug.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Draft release notes complete
Next
From: Qi Huang
Date:
Subject: Strange query planner behavior