| From: | Andrew Chernow <ac(at)esilo(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com> |
| Subject: | Re: Listen / Notify rewrite |
| Date: | 2009-11-12 16:47:30 |
| Message-ID: | 4AFC3C22.5020603@esilo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
>
I simply don't agree that the semantics have to change. You call it a
queue, I call it sesison data. There is no reason why the documentation
can't state that notifies may not be delivered due to crashes, so make
sure to use persistent storage for any payload worth keeping post-session.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2009-11-12 16:49:18 | Re: write ahead logging in standby (streaming replication) |
| Previous Message | Tom Lane | 2009-11-12 16:44:39 | Re: plpgsql GUC variable: custom or built-in? |