Re: listen/notify argument (old topic revisited)

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
>> 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.

Right. But we play similar games already with the existing SI buffer,
to wit:

Writers grab the controlling lock LW_EXCLUSIVE, thereby having sole
access; in this state it's safe for them to examine all the read
pointers as well as examine/update the write pointer (and of course
write data into the buffer itself). The furthest-back read pointer
limits what they can write.

Readers grab the controlling lock LW_SHARED, thereby ensuring there
is no writer (but there may be other readers). In this state they
may examine the write pointer (to see how much data there is) and
may examine and update their own read pointer. This is safe and
useful because no reader cares about any other's read pointer.

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

I thought of that too, but it's not clear how much it'd help. The
writer would have to scan through all the per-reader data while holding
the write lock, which is not good for concurrency. On SMP hardware it
could actually be a net loss. Might be worth experimenting with though.

You could make a good reduction in the shared-memory space needed by
storing just a hash code for the interesting names, and not the names
themselves. (I'd also be inclined to include the hash code in the
transmitted message, so that readers could more quickly ignore
uninteresting messages.)

regards, tom lane