Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!
Date: 2010-08-20 14:15:47
Message-ID: 4C6E8E13.4050307@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20/08/10 16:24, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Hmm, we have pg_usleep() calls in some fairly low-level functions, like
>> mdunlink() and s_lock(). If someone has called SetSleepInterrupt(), we
>> don't want those pg_usleep()s to return immediately. And pg_usleep() is
>> used in some client code too. I think we need a separate sleep function
>> for this.
>
> Well, we'd need some careful thought about which sleeps need what, but I
> don't necessarily have an objection to a separate interruptable sleep
> function.

If we have to, we could also support multiple interrupts with multiple
self-pipes, so that you can choose at pg_usleep() which ones to wake up on.

>> Another idea is to not use unix signals at all, but ProcSendSignal() and
>> ProcWaitForSignal(). We would not need the signal handler at all.
>> Walsender would use ProcWaitForSignal() instead of pg_usleep() and
>> backends that want to wake it up would use ProcSendSignal().
>
> You keep on proposing solutions that only work for walsender :-(.

Well yes, the other places where we use pg_usleep() are not really a
problem as is. If as a side-effect we can make them respond more quickly
to signals, with small changes, that's good, but walsender is the only
one that's performance critical.

That said, a select() based solution is my current favorite.

> Most of the other places where we have pg_usleep actually do want
> a timed sleep, I believe. It's also unclear that we can always expect
> ProcSendSignal to be usable --- for example, stuff like SIGHUP would
> be sent by processes that might not be connected to shared memory.
>
>> The problem
>> is that there is currently no way to specify a timeout, but I presume
>> the underlying semaphore operations have that capability, and we could
>> expose it.
>
> They don't, or at least the semop-based implementation doesn't.

There's semtimedop(). I don't know how portable it is, but it seems to
exist at least on Linux, Solaris, HPUX and AIX. On what platforms do we
use sysv semaphores?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-20 14:18:31 Re: Deadlock bug
Previous Message Robert Haas 2010-08-20 14:01:55 Re: small smgrcreate cleanup patch