Re: Concurrency - Mailing list pgsql-novice

From Mladen Gogala
Subject Re: Concurrency
Date
Msg-id 4CB4CC39.8090800@vmsinfo.com
Whole thread Raw
In response to Re: Concurrency  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Concurrency  (Richard Broersma <richard.broersma@gmail.com>)
List pgsql-novice
Tom Lane wrote:
> Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
>
>> Where is the problem? The problem lies in the fact that the 2nd
>> transaction should have only seen the changes committed before it has
>> begun, ie, x=1.
>>
>
> You might want to go reread this:
> http://www.postgresql.org/docs/9.0/static/transaction-iso.html#XACT-READ-COMMITTED
> If you don't like that behavior, you might want SERIALIZABLE mode
> instead.
>
>             regards, tom lane
>
No, it wasn't about liking or not liking, I was only trying to get to
the bottom of this behavior. In particular, I translated the phrase "
The search condition of the command (the WHERE clause) is re-evaluated "
as the transaction restart and have fully expected the triggers to fire
twice, which didn't happen.  I am comparing Postgres to Oracle, to find
out where should I expect different behavior and where should I expect
exactly the same behavior. So far, I must say, the changes aren't too
big. One of the biggest is the lack of the %ROWCOUNT attribute with
cursors and a different set of exceptions. Also, there is no
DBMS_OUTPUT, I have to use RAISE NOTICE, which feels strange but does
the trick. As a DBA, I should be able to help developers when they do
run into problems. And they will.

--

Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com
The Leader in Integrated Media Intelligence Solutions




pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: Concurrency
Next
From: Richard Broersma
Date:
Subject: Re: Concurrency