Re: listen/notify argument (old topic revisited) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: listen/notify argument (old topic revisited)
Date
Msg-id 25178.1025711282@sss.pgh.pa.us
Whole thread Raw
In response to Re: listen/notify argument (old topic revisited)  (Hannu Krosing <hannu@tm.ee>)
Responses Re: listen/notify argument (old topic revisited)  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.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.

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

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.
        regards, tom lane




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: libpq++ build problems
Next
From: Tom Lane
Date:
Subject: Re: listen/notify argument (old topic revisited)