Gavin Sherry <[EMAIL PROTECTED]> writes:
>> Because there is no other easy way to guarantee message delivery?
> Shared memory is much easier and, to all intents and purposes, as reliable
> for this kind of usage. It is much faster and is the-right-way-to-do-it.
Right. Since we do not attempt to preserve NOTIFY messages over a
system crash, there's no good reason to keep the messages in a table.
Except for the problem that shared memory is of limited size.
But if we are willing to define the semantics in a way that allows
buffer overflow recovery, that can be dealt with.
> A buffer overrun (rare as it would be,
> considering the different usage patterns of the shared memory for
> notification) would result in an elog(ERROR) from within the backend which
> has attempted to execute the notification.
Hmm. That's a different way of attacking the overflow problem. I don't
much care for it, but I can see that some applications might prefer this
behavior to cache-style overrun response (ie, issue forced NOTIFYs on
all conditions). Maybe support both ways?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
