Re: Re: [SQL] PostgreSQL crashes on me :(
От | Ian Lance Taylor |
---|---|
Тема | Re: Re: [SQL] PostgreSQL crashes on me :( |
Дата | |
Msg-id | 20001218175802.29750.qmail@daffy.airs.com обсуждение исходный текст |
Ответ на | Re: Re: [SQL] PostgreSQL crashes on me :( (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [SQL] PostgreSQL crashes on me :(
|
Список | pgsql-hackers |
Date: Mon, 18 Dec 2000 10:41:47 -0500 From: Tom Lane <tgl@sss.pgh.pa.us> ncm@zembu.com (Nathan Myers) writes: > Sounds like a TODO list item: eliminate syscalls from signal handlers. After looking at it some more, I think that's a lot easier said than done. We could try writing the postmaster's SIGCHLDroutine in the same style currently used for SIGHUP --- ie, signal handler just sets a flag that's examined bythe main loop in ServerLoop --- but I don't see any way to guarantee timely response if we do that. If the SIGCHLD happensjust before we reach the select() then the select() will block, and we won't respond to the dying child until thenext connection request arrives or some other signal happens. That's OK under normal scenarios, but highly not OK whena backend has crashed. Any thoughts on a cleaner solution? One way to avoid this race condition is to set a timeout on the select. What is the maximum acceptable time for a timely response? Would executing a few instructions at that time interval impose an unacceptable system load? (Naturally no timeout should be used if there are no child processes.) Ian
В списке pgsql-hackers по дате отправления: