Re: Listen / Notify rewrite

On Thu, Nov 12, 2009 at 11:39 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Joachim Wieland <joe(at)mcknight(dot)de> writes:
>>> However I share Greg's concerns that people are trying to use NOTIFY
>>> as a message queue which it is not designed to be.
>>
>> Yes.  Particularly those complaining that they want to have very large
>> payload strings --- that's pretty much a dead giveaway that it's not
>> being used as a condition signal.
>>
>> Now you might say that yeah, that's the point, we're trying to enable
>> using NOTIFY in a different style.  The problem is that if you are
>> trying to use NOTIFY as a queue, you will soon realize that it has
>> the wrong semantics for that --- in particular, losing notifies across
>> a system crash or client crash is OK for a condition notification,
>> not so OK for a message queue.  The difference is that the former style
>> assumes that the authoritative data is in a table somewhere, so you can
>> still find out what you need to know after reconnecting.  If you are
>> doing messaging you are likely to think that you don't need any backing
>> store for the system state.
>>
>> So while a payload string for NOTIFY has been on the to-do list since
>> forever, I have to think that Greg's got a good point questioning
>> whether it is actually a good idea.
>
> I think there could be cases where the person writing the code can
> know, extrinsic to the system, that lost notifications are OK, and
> still want to deliver a payload.  But I think the idea of enabling a
> huge payload is not wise, as it sounds like it will sacrifice
> performance for a feature that is by definition not essential to

'premature optimization is the root of all evil' :-)

merlin