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 [EMAIL PROTECTED] wrote: > Date: Wed, 27 Oct 2004 13:01:45 +0200 (MET DST) > From: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > 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. > > > > > > --------------------------------------------------------------------------- > > > > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > > ------------------------------------------------------------------------------ > > > 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: [EMAIL PROTECTED] ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery) ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly