Re: BUG #6086: [SOLVED] Segmentation fault

> Linking pthreads into the backend is likely to cause more problems than
> it solves, especially if you're proposing that we do that everywhere.
>
> regards, tom lane

No, I am not proposing that. Not linking to pthread when not needed should
actually be an
optimization since the libc noop stubs get used instead.

I've found the issue now (yes, again :)

Short version:
FreeBSD compiles the main server and contrib modules without and with
pthreads, respectively. No bug in postgresql. If you're in a hurry, no need
to read any further.

Longer version:
With FreeBSD ports, the contrib part is compiled separately. For some
reason, the contrib units are being made to link to pthread, but the server
itself isn't.

So the backend forks to handle a request, some stored procedure touches
some XML, libxml2 thinks it is initializing some mutex by calling some
pthread_ stubs in libc, the stored procedure updates a column which has a
trigram index, postgresql dynamically loads pg_trgm.so, which links to
libpthread, and now the weak libc symbols are overridden and a little bit
later we end up calling a real pthread_ method passing a non-initialized
mutex and get a bus error.

Lots of fun to debug, seeing pthread_self() suddenly changing return value
within a single thread/backend in the middle of processing a single
request..

With a custom (correct) compilation everything functions correctly with an
unmodified libxml2 and postgresql, and without any linking to or preloading
libpthread.

Question is, why are postgresql90-server and postgresql90-contrib compiled
differently ?

It seems it may have been intended as a quick fix for pgbench, as the
configure script for the -contrib port does not end up with "-pthread" in
the PTHREAD_CFLAGS in Makefile.global which breaks compilation of pgbench,
the server does have this, haven't found the reason yet. Side effect is
that all modules link to pthread while the server doesn't ..

I will continue this discussion within FreeBSD, as this is not a PostgreSQL
bug (though if there is ever a loadable contrib module which does need
pthreads the above situation will occur again).

Thanks again to all who helped!

Cheers
Dennis