| From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: background triggers? |
| Date: | 2006-05-25 08:43:43 |
| Message-ID: | 1148546623.20217.214.camel@model.home.waw.pl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2006-05-25 at 10:33 +0200, Thomas Hallgren wrote:
> Rafal Pietrak wrote:
> > I'd like to propose a 'syntax/semantics' of such trigger:
> >
> > Triggers normally execute inside of a transaction.
> >
> > A COMMIT within a trigger could mean: "do a fork: fork-1) return to the
> > main and schedule COMMIT there, fork-2) continue in bacground".
> >
> And what if fork-1) returns to the main, attempts the COMMIT but instead and rolls back due
> to a violated constraint? Where does that leave fork-2?
>
> Regards,
> Thomas Hallgren
No problem at all (at least in particular case of an application I have
in mind :). The precedure that remains within fork-2 just does a time
consuming housekeeping. Like a cleanup - always succeeds, even if
sometimes is not really necesary (like in case of main rolling-back).
And that's exacly why I thing that it should be 'released to run' by
RDBMS *after* the main COMMITS (or ROLLES-BACK). It should be run on
COMMITED (visible to the world) changes, not on session trancients.
-R
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafal Pietrak | 2006-05-25 09:08:27 | Re: background triggers? |
| Previous Message | Holger Hoffstaette | 2006-05-25 08:42:06 | Re: 8.1 on gentoo |