From: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Concurrency |
Date: | 2010-10-12 20:59:37 |
Message-ID: | 4CB4CC39.8090800@vmsinfo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Tom Lane wrote:
> Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Broersma | 2010-10-12 21:07:25 | Re: Concurrency |
Previous Message | Tom Lane | 2010-10-12 20:42:50 | Re: Concurrency |