Amit Kumar <helloamit5@xxxxxxxxx> writes: > <snip> > Jul 30 12:40:36 dell16 postgres[11088]: [11-1] 2012-07-30 12:40:36 IST > [11088]: [10-1] user=postgres,db=dbpush xxxxxxxxxxxxxxxxxx(43225)LOG: > statement: START TRANSACTION > Jul 30 12:40:36 dell16 postgres[11088]: [12-1] 2012-07-30 12:40:36 IST > [11088]: [11-1] user=postgres,db=dbpush xxxxxxxxxxxxxxxxxx(43225)LOG: > statement: *UPDATE dbpush_camp_main SET status=7 WHERE camp_id IN(137721)* > Jul 30 12:40:36 dell16 postgres[11088]: [13-1] 2012-07-30 12:40:36 IST > [11088]: [12-1] user=postgres,db=dbpush xxxxxxxxxxxxxxxxxx(43225)LOG: > statement: COMMIT > Jul 30 12:40:36 dell16 postgres[9368]: [5-1] 2012-07-30 12:40:36 IST > [9368]: [4-1] user=postgres,db=dbpush xxxxxxxxxxxxxxxxxx(43187)LOG: > statement: SELECT status FROM dbpush_camp_main WHERE camp_id=137721 > </snip> I assume what you're complaining about is that PID 9368's select didn't see the result of pid 11088's update? The above trace doesn't prove that anything is wrong. That behavior would be expected if 9368 had taken its "snapshot" before 11088's commit finished, and you can't really tell if that was the case or not from these log entries. But given they all happened in less than 1 second, it's certainly possible. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
