From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | 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:35:56 |
Message-ID: | 4B0557CC.7050208@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joachim Wieland wrote:
> On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, did we discuss the issue of 2PC transactions versus notify?
>> The current behavior of 2PC with notify is pretty cheesy and will
>> become more so if we make this change --- you aren't really
>> guaranteed that the notify will happen, even though the prepared
>> transaction did commit. I think it might be better to disallow
>> NOTIFY inside a prepared xact.
That will make anyone currently using 2PC with notify/listen unhappy.
> 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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2009-11-19 14:51:14 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Andrew Dunstan | 2009-11-19 14:17:28 | Re: xpath_table equivalent |