Re: Unixware 714 pthreads
От | ohp@pyrenet.fr |
---|---|
Тема | Re: Unixware 714 pthreads |
Дата | |
Msg-id | Pine.UW2.4.53.0410272225340.12665@server.pyrenet.fr обсуждение исходный текст |
Ответ на | Re: Unixware 714 pthreads (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
On Wed, 27 Oct 2004, Bruce Momjian wrote: > Date: Wed, 27 Oct 2004 14:53:26 -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 > > ohp@pyrenet.fr wrote: > > 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. > > My guess is that there is some problem with delivering alarm signals > because that is how the timeout code works. > That's my guess too. I've traked that to src/backend/storage/lmrg/proc.c where kill is called. Unixware doc says that kill to self_proc id delivers the signal to the thread that called it. For some reason, this backend has 2 threads (can't figure why) and INMHO kill should be pthread_kill. I wanted to try but found no way to find the other thread_id. I need the help of postgresql/thread guru here. Many thanks > -- 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)
В списке pgsql-hackers по дате отправления: