Re: timeout implementation issues
Hiroshi Inoue <inoue@tpf.co.jp>
From: Hiroshi Inoue <Inoue@tpf.co.jp>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, Michael Loftis <mloftis@wgops.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2002-04-10T04:31:58Z
Lists: pgsql-hackers
Bruce Momjian wrote: > > Hiroshi Inoue wrote: > > > > ??? What do you mean by > > > > o Some SETs are honored in an aborted transaction (current) > > > > ? > > > > Is the current state different from > > > > o All SETs are honored in an aborted transaction > > > > ? > > > > > > In the case of: > > > > > > BEGIN WORK; > > > SET x=1; > > > bad query that aborts transaction; > > > SET x=2; > > > COMMIT WORK; > > > > > > Only the first SET is done, so at the end, x = 1. If all SET's were > > > honored, x = 2. If no SETs in an aborted transaction were honored, x > > > would equal whatever it was before the BEGIN WORK above. > > > > IMHO > > o No SETs are honored in an aborted transaction(current) > > > > The first SET isn't done in an aborted transaction. > > I guess my point is that with our current code, there is a distinction > that SETs are executed before a transaction aborts, but are ignored > after a transaction aborts, even if the SETs are in the same > transaction. Not only SET commands but also most commands are ignored after a transaction aborts currently. SET commands are out of transactional control but it doesn't mean they are never ignore(rejecte)d. regards, Hiroshi Inoue