| From: | Simon Riggs <simon(at)2ndQuadrant(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 |
| Subject: | Re: Listen / Notify rewrite |
| Date: | 2009-11-15 22:20:58 |
| Message-ID: | 1258323658.14054.3154.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote:
> >> 3. Every distinct notification is delivered.
> >> Regarding performance, the slru-queue is not fsync-ed to disk
>
> > These two statements seem to be in opposition. How do you know a
> > notification will be delivered if the queue is non-recoverable?
>
> 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.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-11-15 22:32:33 | Re: patch - Report the schema along table name in a referential failure error message |
| Previous Message | Brendan Jurd | 2009-11-15 22:18:36 | Re: patch - Report the schema along table name in a referential failure error message |