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: 20050212211610.GA24118@winnie.fuhr.org (view raw or flat)
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/plpython.so":
dlopen '/usr/local/pgsql80/lib/plpython.so' failed.
(/usr/local/lib/python2.4/config/libpython2.4.so: 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]
$$ LANGUAGE plpythonu IMMUTABLE STRICT;

SELECT foo(1234);
NOTICE:  sem_init() called
NOTICE:  sem_wait() called
NOTICE:  sem_post() called
NOTICE:  pthread_self() called
...
 foo  
------
 1234
(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);
 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 pthread_phony.so file contains stub versions of the following
functions; all were required to stop the linker from complaining:

pthread_attr_destroy
pthread_attr_init
pthread_attr_setstacksize
pthread_create
pthread_detach
pthread_self
sem_destroy
sem_init
sem_post
sem_trywait
sem_wait

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
http://www.fuhr.org/~mfuhr/

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-2014 The PostgreSQL Global Development Group