Re: Notify enhancement

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Notify enhancement
Date: 2006-12-18 20:25:08
Message-ID: 4586F924.1040709@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>>> Are we keeping use of SIGUSR2 in this scheme?
>>>
>
>
>> What for? Just protect the write pointer with a lwlock and have
>> listeners check whether somebody has written something.
>>
>
> You do want something comparable to SIGUSR2 to prod active backends to
> consume messages, in case they are busy doing a query and hence not
> checking the ring. I'm envisioning something like having the SIGUSR2
> signal handler set a flag that's checked by CHECK_FOR_INTERRUPTS(),
> and if set then ProcessInterrupts will go off and absorb messages.
> Onlookers can tell who's falling behind by noting where their read
> pointers are, and can issue SIGUSR2 to the laggards --- in particular,
> any backend that finds itself unable to insert a NOTIFY into the ring
> for lack of space can SIGUSR2 the laggards and then sleep a little.
>
>
>

I just wondered idly if we could piggyback on the existing
WAKEN_CHILDREN/SIGUSR1 mechanism? It might mean we signal more children
than necessary, but most won't have much to do anyway.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike G 2006-12-18 20:32:29 Typo in pg_dump documentation and new suggestion for Release Notes
Previous Message Greg Sabino Mullane 2006-12-18 20:24:07 Re: Vaccuming dead rows on busy databases