| From: | "Ian Harding" <iharding(at)destinydata(dot)com> |
|---|---|
| To: | "Flemming Frandsen" <ff(at)partyticket(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: LISTEN considered dangerous |
| Date: | 2006-08-02 13:46:12 |
| Message-ID: | 725602300608020646gb908d7et1e91cfe24aab86f@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 8/2/06, Flemming Frandsen <ff(at)partyticket(dot)net> wrote:
> Ian Harding wrote:
> > 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.
>
> Yes, that's very nice, but it doesn't have *anything* to do with what I
> posted about.
>
Quite true, but it does indicate, to me at least, the fact that this
is a SQL command and doesn't take effect until committed.
From what I read in the docs, I would expect the NOTIFY signals to be
like phone calls, if your phone's not plugged in (LISTEN not
committed) you miss the call. That's the way it works apparently.
> I'm bothered by listen listening from the end of the transaction in
> stead of the start of the transaction.
>
What seems to be needed is an answering service that will record your
NOTIFY events, in case you decide to plug in the phone and retrieve
them.
- Ian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Weimer | 2006-08-02 13:46:59 | Re: ECPG and COPY |
| Previous Message | Bruce Momjian | 2006-08-02 13:37:01 | Re: ECPG and COPY |