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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 20/08/10 17:28, Tom Lane wrote:
>> Well, yes they are. They cause unnecessary process wakeups and thereby
>> consume cycles even when the database is idle. See for example a
>> longstanding complaint here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=252129
>>
>> If we're going to go to the trouble of having a mechanism like this,
>> I'd like it to fix that problem so I can close out that bug.

> Hmm, if you want to put bgwriter and walwriter to deep sleep, then
> someone will need to wake them up when they have work to do. Currently
> they poll. Maybe they should just sleep longer, like 10 seconds, if
> there hasn't been any work to do in the last X wakeups.

I should probably clarify that I don't expect this patch to solve that
problem all by itself. But ISTM that a guaranteed-interruptible version
of pg_usleep is a necessary prerequisite before we can even think about
dialing down the database's CPU consumption at idle.

> We've been designing the new sleep facility so that the event that wakes
> up the sleep is sent from the signal handler in the same process, but it
> seems that all the potential users would actually want to be woken up
> from *another* process, so the signal handler seems like an unnecessary
> middleman.

No, because there are also lots of cases where the signal is arriving
from a non-Postgres process; SIGTERM arriving from init being the killer
case that you simply don't get to propose an alternative design for.
More generally, I'm uninterested in decoupling cases like SIGHUP for
postgresql.conf change from the existing signal mechanism, because it's
just too useful to be able to trigger that externally.

> Particularly on Windows where signals are simulated with
> pipes and threads, while you could just send a Windows event directly
> from one process to another.

Windows of course has different constraints, and in particular it lacks
the constraint that we must be able to respond to system-defined
signals. So I wouldn't object to the underlying implementation being
different for Windows.

> [ "latch" proposal ]

This seems reasonably clean as far as signal conditions generated
internally to Postgres go, but I remain unclear on how it helps for
response to actual signals.

regards, tom lane