From: | Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar> |
---|---|
To: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: transaction and triggers |
Date: | 2008-01-18 15:16:04 |
Message-ID: | 4790C2B4.1070103@fmed.uba.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Filip Rembiałkowski wrote:
>2008/1/18, Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar>:
>
>
>>Hi all. Im puzzled again. Just thinking:
>>
>>As im having fun trying to make my own replication system, im stuck in
>>this situation:
>>Consider a simple table with a unique index on the `id' field, and a
>>function who will fail, such as
>>
>>insert into test (id) values (1);
>>insert into test (id) values (1);
>>
>>This will fail and the transaction will be rollback'ed, but as the basis
>>of my replication system is on row level triggers, the first time the
>>insert is called, the trigger will be executed, and i will like to be
>>able to stack the triggers in some way, in order to be fired only after
>>a succesfull execution of the hole function.
>>
>>
>
>If the transaction is rolled back, changes made by your trigger to
>local database will be also canceled.
>
>Unless you make any manipulation on remote databases, you have no problem.
>
>Any changes made to remote databases, for example if you call some
>dblink functions, are not transactional, and will not be rolled back.
>
>In this case you have to rethink your design, as there is no "ON
>COMMIT" trigger (yet?)
>
>
Right. But today, that trigger do some other work, wich includes
writing some files to disk, so there is my problem. Crap, i guess i will
have to review the main logic.
Thanks!
Gerardo
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-18 15:26:25 | Re: transaction and triggers |
Previous Message | Filip Rembiałkowski | 2008-01-18 14:42:21 | Re: transaction and triggers |