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

Re: notification payloads

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Dave Page <dpage(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: notification payloads
Date: 2007-04-03 17:21:05
Message-ID: 46128D01.90105@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)net> writes:
>   
>> Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
>>     
>>> Er, what listen table? 
>>>       
>
>   
>> At least the list of which backends listen to which events should be
>> also in shared mem.
>>     
>
> No, the intent is specifically that there will be *no* such global
> structure.  All it does is add complexity, not to mention make it
> harder to size shared memory.
>
>   
>> How else would we know how many copies to make for each backend or when
>> we can release the memory in case we make one copy ?
>>     
>
> The proposed design is essentially a clone of the sinval messaging
> system, which does not need to know either of those and does not make
> "one copy per backend".  There's one copy, period.
>
>
>   

Further design notes:

What we will need to keep track of (a la sinval) is a queue pointer per 
backend. I think we can add an optimization to that by keeping a count 
of events listened to per backend, so that we only wake up active 
listeners. For non listeners we can just catch them up without bothering 
to wake them. This will help to avoid the potential for a "thundering 
herd" effect that has apparently bothered some people.

We'll also need to store the database id along with the event name and 
message, since pg_listener is per db rather than per cluster.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2007-04-03 17:37:27
Subject: Re: Synchronized Scan benchmark results
Previous:From: Tom LaneDate: 2007-04-03 17:10:59
Subject: Re: Implicit casts to text

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