From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fixing LISTEN/NOTIFY |
Date: | 2005-10-08 20:59:22 |
Message-ID: | 736.1128805162@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> Maybe I'm missing something, but is it possible to ensure notifications
> aren't lost using Heikki's method, since everything's only in shared
> memory? Or is the idea that stuff would not survive a backend crash?
Listen/notify state has never survived a crash (since it is defined in
terms of PIDs that will no longer exist after a DB restart), and I don't
really see any reason why we'd want it to. An application reconnecting
after a DB crash would have to assume it might have missed some
notifications occurring before it could reconnect, and would have to
re-determine what the database state is anyway.
But I think you might be confusing that with the feature-or-bug
(depending on one's point of view) that duplicate notifications can be
merged into one event. I'm inclined to preserve that behavior,
primarily because not doing so would create a tremendous penalty on
applications that expect it to work that way. With addition of payload
data it'd be easy for apps that don't want merging to prevent it: just
add an otherwise-uninteresting serial number to the payload string.
We'd certainly want to define the "duplicate" test to consider the
payload string as well as the topic name.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-10-08 21:07:21 | Re: Vote needed: revert beta2 changes or not? |
Previous Message | Jim C. Nasby | 2005-10-08 20:57:36 | Re: Vote needed: revert beta2 changes or not? |