Re: Functions and transactions

 transaction_isolation
-----------------------
 read committed

Running Postgres 7.4  btw

Kris

Tsirkin Evgeny wrote:

>
> What transaction level are you using?
> Evgeny.
> Kris Kiger wrote:
>
>> Here is my problem.  I have a function that is triggered on insert.
>> For simplicity's sake, lets say the function looks like this:
>>
>> CREATE OR REPLACE FUNCTION dostuff_on_insert() RETURNS TRIGGER AS '
>> DECLARE lockrows RECORD;
>> BEGIN
>>    select into lockrows * from table1 where pkey_id = NEW.pkey_id for
>> update on table1;
>>    update table1 set active = false where NEW.pkey_id = pkey_id and
>> active;
>>    NEW.active := true;
>> END;
>> 'language 'plpgsql';
>>
>> I have two inserts, lets say insert A and insert B.  A new explicit
>> transaction block is started with the intent of executing insert A.
>>
>> begin;
>> insert into table1 (stuff) VALUES (morestuff);
>>
>>
>> At this time another terminal is opened up and insert B is executed
>> in the same fasion:
>>
>> begin;
>> insert into table1 (stuff) VALUES (different_more_stuff);
>>
>> In my two open terminals insert A has completed and insert B is
>> waiting for insert A's transaction to be committed, before it can
>> move on.  I commit insert A and check to see how many active row's I
>> have for that ID (there should be 1, the new row).
>>
>> commit;
>> select * from table1;
>>
>> I find that there is one active row.  Everything is fine at this
>> point.  Now, I commit insert B, that has just finished, because
>> insert A has been committed.  I expect to see 1 active row, because
>> the update contained in the function has not been executed, and has
>> therefore not grabbed a snapshot of the table yet.  I expect that the
>> new row from insert A will be updated as well.
>>
>> commit;
>> select * from table1;
>>
>> To my surprise, I see 2 active rows.  What i'm assuming is happening
>> with the transaction must be flawed.  Does the function handle a
>> transaction outside of the one the insert is using?  Just trying to
>> figure out what exactly is going on and why.
>> Thanks in advance for the insight.  If it would be easier to
>> understand by having me paste what is happening directly from the
>> terminals, let me know.
>>
>> Kris
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>
>