From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com> |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-12 16:40:57 |
Message-ID: | b42b73150911120840r1fea2a9cvb21dc2e42f74e5b9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
You guys are assuming it's being used in a queue, which is only a
fraction of cases where this feature is useful. In fact, having a
payload can remove the need for a queue completely where is currently
required for no other reason to deliver payload messages.
I'm sorry, the 128 character limit is simply lame (other than for
unsolvable implementation/performance complexity which I doubt is the
case here), and if that constraint is put in by the implementation,
than the implementation is busted and should be reworked until it's
right. A feature that is being used for things not intended is a sign
of a strong feature, not a weak one, and the idea that a payload
should be length limited in order to prevent use in ways that are
'wrong' is a very weak argument IMO. People have been asking for this
feature since the beginning of time, and nobody said: 'please limit it
to 128 bytes'. A limit of 4k - 64k is much more appropriate if you
even want a hard limit at all...
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-11-12 16:42:42 | Re: Listen / Notify rewrite |
Previous Message | Robert Haas | 2009-11-12 16:39:00 | Re: Listen / Notify rewrite |