Re: Listen / Notify rewrite - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Listen / Notify rewrite
Date
Msg-id 4375.1258043412@sss.pgh.pa.us
Whole thread Raw
In response to Re: Listen / Notify rewrite  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Listen / Notify rewrite
Re: Listen / Notify rewrite
Re: Listen / Notify rewrite
Re: Listen / Notify rewrite
Re: Listen / Notify rewrite
List pgsql-hackers
Joachim Wieland <joe@mcknight.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: plpgsql GUC variable: custom or built-in?
Next
From: Simon Riggs
Date:
Subject: Re: next CommitFest