Re: background triggers?
От | Rafal Pietrak |
---|---|
Тема | Re: background triggers? |
Дата | |
Msg-id | 1148546623.20217.214.camel@model.home.waw.pl обсуждение исходный текст |
Ответ на | Re: background triggers? (Thomas Hallgren <thomas@tada.se>) |
Ответы |
Re: background triggers?
|
Список | 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
В списке pgsql-general по дате отправления: