Skip site navigation (1) Skip section navigation (2)

Re: BUG #1473: Backend bus error, possibly due to ANALYZE

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Brian B(dot)" <brian-pgsql(at)bbdab(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1473: Backend bus error, possibly due to ANALYZE
Date: 2005-02-12 21:16:10
Message-ID: (view raw or whole thread)
Lists: pgsql-bugs
I haven't been following this thread closely, but if I understand
correctly then the problems are the result of linking PostgreSQL
against libc_r instead of libc on FreeBSD (at least FreeBSD 4.x),
which was done in an attempt to make plpythonu work.  Otherwise
attempting to createlang plpythonu results in the following error:

createlang: language installation failed:
ERROR:  could not load library "/usr/local/pgsql80/lib/":
dlopen '/usr/local/pgsql80/lib/' failed.
(/usr/local/lib/python2.4/config/ Undefined symbol "pthread_attr_destroy")

Is that right?

What I'm about to describe is a hack and it's probably wrong and
dangerous, but I did it as an experiment anyway to see what would
happen.  I'm in no way suggesting that anybody should try it except
on a test server that can tolerate failure and data corruption.

I created a .so file with stub versions of the missing functions
and used preload_libraries to load it into the PostgreSQL backend.
I built PostgreSQL "normally", i.e., without linking against libc_r.

It worked, at least in simple tests.

Pthreads functions generally return 0 on success or some errno value
on failure.  Most functions have EINVAL as a documented return value,
so I wrote all of the stub versions to return EINVAL -- I figured that
they should report failure instead of success because they don't
actually do anything.  I also used ereport() to log the fact that a
function was called.

CREATE FUNCTION foo(integer) RETURNS integer AS $$
return args[0]

SELECT foo(1234);
NOTICE:  sem_init() called
NOTICE:  sem_wait() called
NOTICE:  sem_post() called
NOTICE:  pthread_self() called
(1 row)

The stub functions are called only when the language handler is
first loaded -- subsequent calls to plpythonu functions don't print
any of the notices, at least not that I've seen so far:

SELECT foo(5678);
(1 row)

It's interesting that although all of the stub functions report
failure, the code runs anyway.  It makes one wonder how thorough
the error checking is.

My file contains stub versions of the following
functions; all were required to stop the linker from complaining:


Again, this was nothing more than an experiment, and so far I've
done only a few simple tests.  It could very well cause the system
to crash and burn.  Don't try it unless you can afford to have your
database trashed.

Michael Fuhr

In response to

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2005-02-13 00:16:48
Subject: Re: BUG #1415: odbc driver SQLGetInfo SQL_CATALOG_TERM returns
Previous:From: GlenDate: 2005-02-12 20:51:23
Subject: BUG #1480: A wildcard for the listen address doesn't work

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group