From: | Gregory Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | harding(dot)ian(at)gmail(dot)com |
Cc: | "Flemming Frandsen" <ff(at)partyticket(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: LISTEN considered dangerous |
Date: | 2006-08-01 23:50:19 |
Message-ID: | 87r700vww4.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Ian Harding" <harding(dot)ian(at)gmail(dot)com> writes:
> > However that just doesn't work, because listen is broken, allow me to
> > illustrate, here A and B are two clients:
> >
> > A: BEGIN
> > A: SELECT * FROM foo and cache the result.
> > A: LISTEN foochange
> > B: BEGIN
> > B: update foo
> > B: NOTIFY foochange
> > B: COMMIT
> > A: COMMIT
> >
> From the docs:.
>
> NOTIFY interacts with SQL transactions in some important ways.
> Firstly, if a NOTIFY is executed inside a transaction, the notify
> events are not delivered until and unless the transaction is
> committed. This is appropriate, since if the transaction is aborted,
> all the commands within it have had no effect, including NOTIFY. But
> it can be disconcerting if one is expecting the notification events to
> be delivered immediately.
Note that he's not complaining about when the NOTIFY takes effect. He's
complaining about when the LISTEN takes effect.
I haven't used LISTEN/NOTIFY myself yet and I do indeed find the behaviour he
shows somewhat surprising. Normally in read-committed mode uncommitted
transactions are affected by other transactions when they commit. In this case
the uncommitted LISTEN is not being affected by the committed NOTIFY.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Carlo Stonebanks | 2006-08-02 00:32:43 | Re: Where do Tcl questions go? |
Previous Message | Reece Hart | 2006-08-01 23:33:04 | Re: proper use of array datatype |