On Wed, 2002-07-03 at 15:51, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > Are you planning to have one circular buffer per listening backend ?
>
> No; one circular buffer, period.
>
> Each backend would also internally buffer notifies that it hadn't yet
> delivered to its client --- but since the time until delivery could vary
> drastically across clients, I think that's reasonable. I'd expect
> clients that are using LISTEN to avoid doing long-running transactions,
> so under normal circumstances the internal buffer should not grow very
> large.
>
> regards, tom lane
> 2. On receipt of signal: grab read lock on shared-memory circular
> buffer, copy all data up to write pointer into private memory,
> advance my (per-process) read pointer, release lock. This would be
> safe to do pretty much anywhere we're allowed to malloc more space,
> so it could be done say at the same points where we check for cancel
> interrupts. Therefore, the expected time before the shared buffer
> is emptied after a signal is pretty small.
>
> In this design, if someone sits in a transaction for a long time,
> there is no risk of shared memory overflow; that backend's private
> memory for not-yet-reported NOTIFYs could grow large, but that's
> his problem. (We could avoid unnecessary growth by not storing
> messages that don't correspond to active LISTENs for that backend.
> Indeed, a backend with no active LISTENs could be left out of the
> circular buffer participation list altogether.)
There could a little more smartness here to avoid unneccessary copying
(not just storing) of not-listened-to data. Perhaps each notify message
could be stored as
(ptr_to_next_blk,name,data)
so that the receiving backend could skip uninetersting (not-listened-to)
messages.
I guess that depending on the circumstances this can be either faster or
slower than copying them all in one memmove.
This will be slower if all messages are interesting, this will be an
overall win if there is one backend listening to messages with big
dataload and lots of other backends listening to relatively small
messages.
There are scenarios where some more complex structure will be faster (a
sparse communication structure, say 1000 backends each listening to 1
name and notifying ten others - each backend has to (manually ;) check
1000 messages to find the one that is for it) but your proposed
structure seems good enough for most common uses (and definitely better
than the current one)
---------------------
Hannu