| From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Listen / Notify - what to do when the queue is full |
| Date: | 2009-11-19 14:51:14 |
| Message-ID: | 4B055B62.3020203@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Joachim Wieland wrote:
>> On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yes, I have been thinking about that also. So what should happen
>> when you prepare a transaction that has sent a NOTIFY before?
>
> From the user's point of view, nothing should happen at prepare.
>
> At a quick glance, it doesn't seem hard to support 2PC. Messages should
> be put to the queue at prepare, as just before normal commit, but the
> backends won't see them until they see that the XID has committed.
Yeah, but if the server is restarted after the PREPARE but before the
COMMIT, the notification will be lost, since all notification queue
entries are lost upon restart with the slru design, no?
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-11-19 14:53:58 | Re: xpath_table equivalent |
| Previous Message | Heikki Linnakangas | 2009-11-19 14:35:56 | Re: Listen / Notify - what to do when the queue is full |