| From: | Milan Krcmar <milan(dot)krcmar(at)seznam(dot)cz> |
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: External (asynchronous) notifications of database updates |
| Date: | 2005-06-20 18:35:46 |
| Message-ID: | 20050620183546.GA20488@mrsk.din.cz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hello Mike,
thanks a lot for your posting!
> Have you considered using LISTEN/NOTIFY? The listener should receive
> notifications only if the notifying transaction commits.
Yes. I've seen them in the documentation _but_ missed the information
about the notification being delivered after the notifier successfuly
commits. Great! This is a (very basic) approach to my problem, although
it requires me to create a mechanism exploring what row was exactly
changed and how. I might readopt the triggers to ask them for some help,
but with caution as race-conditions could easily appear. Thank you for
the clue!
> > I don't know how the various replication tools solve this - do you?
>
> Not sure; maybe some of the people who work on such tools can
> comment.
Still an unresolved issue. Those replication tools must have existed
before the LISTEN/NOTIFY mechanism has been introduced to PG. Have they?
> What do you mean by "notification"? A trigger-based notification? Or
> are you already using LISTEN/NOTIFY?
I meant a trigger-based notification, let's forget this for now.
-
Milan Krcmar
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Együd Csaba | 2005-06-20 18:41:10 | Re: Making the DB secure |
| Previous Message | hubert depesz lubaczewski | 2005-06-20 17:58:13 | Re: Making the DB secure |