Re: listen/notify argument (old topic revisited)

On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > but we are already attracting a thundering herd by
> > sending a signal to all _possibly_ interested backends at the same time
>
> That's why it's so important that the readers use a sharable lock. The
> only thing they'd be locking out is some new writer trying to send (yet
> another) notify.

But there must be some way to communicate the positions of read pointers
of all backends for managing the free space, lest we are unable to know
when the buffer is full.

I imagined that at least this info was kept in share memory.

> Also, it's a pretty important optimization to avoid signaling backends
> that are not listening for any notifies at all.

But of little help when they are all listening to something ;)

> We could improve on it further by keeping info in shared memory about
> which backends are listening for which notify names, but I don't see
> any good way to do that in a fixed amount of space.

A compromize would be to do it for some fixed amount of mem (say 10
names/backend) and assume "all" if out of that memory.

Notifying everybody has less bad effects when backends listen to more
names and keeping lists is pure overhead when all listeners listen to
all names.

--------------
Hannu