Message-ID: <4790C2B4.1070103@fmed.uba.ar>
Date: Fri, 18 Jan 2008 12:16:04 -0300
From: Gerardo Herzig <gherzig@fmed.uba.ar>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
MIME-Version: 1.0
To: =?UTF-8?B?RmlsaXAgUmVtYmlhxYJrb3dza2k=?= <plk.zuber@gmail.com>
CC: pgsql-sql@postgresql.org
Subject: Re: transaction and triggers
References: <4790B50A.5050101@fmed.uba.ar>
	<92869e660801180642i1fdd417r3d3b9399c5e5ab98@mail.gmail.com>
In-Reply-To: <92869e660801180642i1fdd417r3d3b9399c5e5ab98@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Filip Rembiałkowski wrote:

>2008/1/18, Gerardo Herzig <gherzig@fmed.uba.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