Re: Re: [SQL] PostgreSQL crashes on me :(

From: Ian Lance Taylor <ian(at)airs(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [SQL] PostgreSQL crashes on me :(
Date: 2000-12-18 17:58:02
Message-ID: 20001218175802.29750.qmail@daffy.airs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Date: Mon, 18 Dec 2000 10:41:47 -0500
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

ncm(at)zembu(dot)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 SIGCHLD routine in the
same style currently used for SIGHUP --- ie, signal handler just sets
a flag that's examined by the main loop in ServerLoop --- but I don't
see any way to guarantee timely response if we do that. If the SIGCHLD
happens just before we reach the select() then the select() will block,
and we won't respond to the dying child until the next connection
request arrives or some other signal happens. That's OK under normal
scenarios, but highly not OK when a 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-12-18 18:03:34 Re: Re: [HACKERS] 7.1 features list
Previous Message Tom Lane 2000-12-18 17:40:32 Re: Re: [SQL] PostgreSQL crashes on me :(

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2000-12-18 18:18:26 Re: Re: [SQL] PostgreSQL crashes on me :(
Previous Message Tom Lane 2000-12-18 17:54:17 Re: Best database structure for timely ordered values