Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group