Re: Unixware 714 pthreads

Sorry to follow up my own post.

I made some more tests:
create table foo (f1 int) -- for it not to be removed if if kill the
process

each time I do:
psql template1
template1# set statement_timeout=1000;
SET
template1 select block_me();

it works ok

if i do it a second time in the same session, blockme() never returns

I wonder if handle_sig_alarm is re-armed after being used or if sleep is
used anywhere in the backend.

Unixware doc for setitimer
(http://www.pyrenet.fr:8458/en/man/html.3C/getitimer.3C.html)
says that "A sleep following a setitimer wipes out knowledge of the user
signal handler"

What can I do next?

Regards
On Wed, 27 Oct 2004 ohp@pyrenet.fr wrote:

> Date: Wed, 27 Oct 2004 13:01:45 +0200 (MET DST)
> From: ohp@pyrenet.fr
> Newsgroups: comp.databases.postgresql.hackers
> Subject: Re: Unixware 714 pthreads
>
> Dear Bruce,
>
> Thanks for your reply, I was desperate I did'nt get one!
>
> As I said, I'm quite sure there is a bug in pthread library, Before saying
> this to SCO, I have to prove it. Postgresql is the way to prove it!
>
> What I need is to know where to start from (I'd like to put elogs where
> statement_timeout is processed to see what really happens and why it
> doesn't cancel the query).
>
> Could someone tell me where to look for? If anyone is interessed in
> debugging this issue with me, I can set up  an account on a test unixware
> machine.
>
> TIA
>  On Tue, 26 Oct 2004, Bruce Momjian wrote:
>
> > Date: Tue, 26 Oct 2004 17:59:17 -0400 (EDT)
> > From: Bruce Momjian <pgman@candle.pha.pa.us>
> > To: ohp@pyrenet.fr
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Unixware 714 pthreads
> >
> >
> > The only help I can be is that on Unixware (only) the backend is
> > compiled with threading enabled.  This might be showing some thread
> > bugs.
> >
> >
> > ---------------------------------------------------------------------------
> >
> > ohp@pyrenet.fr wrote:
> > > Hi every one,
> > >
> > > I need help to debug the problem I have on Unixware 714 and beta3.
> > > postgresql make check hangs on plpgsql test when compiled with
> > > --enable-thread-safty.
> > >
> > > It does hang on select block_me();
> > >
> > > This select should be canceled by the set statement_timeout=1000, instead,
> > > the backend is 100% CPU bound and only kill -9 can kill it.
> > >
> > > It works ok when compiled without -enable-thread-safty.
> > >
> > > I've tried almost every thing I could think of, but not knowing so much
> > > about threads and PG source code, I request that someone can help me as to
> > > find a way to debug this. It worked up until beta2, but I'm not sure
> > > block_me()was there.
> > >
> > > I really need someone to tell me where to begin.
> > >
> > > TIA
> > >
> > > --
> > > Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
> > > 6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
> > > 31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
> > > FRANCE                          Email: ohp@pyrenet.fr
> > > ------------------------------------------------------------------------------
> > > Make your life a dream, make your dream a reality. (St Exupery)
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 9: the planner will ignore your desire to choose an index scan if your
> > >       joining column's datatypes do not match
> > >
> >
> >
>
>

-- 
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)