From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-16 14:14:40 |
Message-ID: | 2a14a239fec5e2a2160cf4801c81d313@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
>> You misunderstand the requirements. LISTEN notifications are *not*
>> meant to survive a database crash, and never have been. However,
>> so long as both client and server stay up, they must be reliable.
>> If the client has to poll database state because it might have
>> missed a notification, the feature is just a waste of time.
> Why would it be so important for messages to be reliable if
> the database is up, yet its OK to lose messages if it crashes? The
> application must still allow for the case that messages are lost.
Well, there are many use cases. For example, Bucardo uses notifications
to let it know that a table has changed. If the database crashes,
Bucardo is going to restart - as part of its startup routine, it checks
all tables manually for changes, eliminating the need for the NOTIFYs
to survive the crash.
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200911160910
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAksBXkAACgkQvJuQZxSWSsjEWACePcT+65HQ0dvx52PjjTkdMzVS
ELMAnAhR3Ll016/EwPdizzS5BcsuXaw9
=jds6
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-11-16 14:14:58 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Ron Mayer | 2009-11-16 12:19:53 | Re: ORDER BY vs. volatile functions |