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
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 |