Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date: 2010-09-03 02:08:08
Message-ID: 10392.1283479688@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> + * XXX: Is it safe to elog(ERROR) in a signal handler?
>>
>> No, it isn't.

> We should use elog(FATAL) or check proc_exit_inprogress, instead?

elog(FATAL) is *certainly* not a better idea. I think there's really
nothing that can be done, you just have to silently ignore the error.
BTW, if we retry, there had probably better be a limit on how many times
to retry ...

> + if (errno != EAGAIN && errno != EWOULDBLOCK)
> + {
> + /*
> + * XXX: Is it safe to elog(ERROR) in a signal handler?
> + */
> + elog(ERROR, "write() on self-pipe failed: %m");
> + }
> + if (errno == EINTR)
> + goto retry;

> "errno == EINTR)" seems to be never checked.

Another issue with coding like that is that it supposes elog() won't
change errno.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Max Bowsher 2010-09-03 02:34:47 Re: git: uh-oh
Previous Message Fujii Masao 2010-09-03 02:02:25 Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)