On Thu, Mar 18, 2010 at 5:55 AM, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> wrote:
> Slide 9 says:
> Events can be lost!
> – If the same event occurs between two calls on
> collection by a backend, it will only see one of them
> – Because pg_listener has one row per (event,
> listener) pair.
> And I think these limitations are being remedied by the new implementation
> in 9.0.
Anything that describes notifications as "events" is on the wrong
track. This isn't a queueing system, it's a facility is analogous to
unix signals or hardware interrupts -- notifications are condition
variables. If your cache is invalidated twice you only need to know
that it was invalidated, not how many times.
Queueing systems are hard, you have to deal with large volumes of
short-lived data and deal with things like priorities and so on.
Interrupt mechanisms are easy, they're just a small set of flags that
need to be flipped and checked at the right time.
In response to
pgsql-novice by date
|Next:||From: Ryan Garvey||Date: 2010-03-22 16:02:12|
|Subject: How do you query all columns and all tables for a specific string|
|Previous:||From: A. Kretschmer||Date: 2010-03-22 08:07:31|
|Subject: Re: Speed question - new view using preview view components|