On Thu, Jan 29, 2004 at 01:33:48PM -0400, Marc G. Fournier wrote:
> What happens if I abort on the first transaction? If I'm reading this
Doesn't matter, because your second transaction doesn't read any of the
changes you're making there--until (and if) that first one commits. The
second transaction simply doesn't care if the the first has been aborted
or is still running. It would if the transaction level were READ
UNCOMMITTED, but with postgres we don't need to worry about that.
> right, if Trans2 does the exact same as above, and COMMITs before Trans1
> Aborts, the value of balance becomes +200 (Trans2 + Trans1) ... but what
> happens when Trans1 ABORTS? Trans2 believes its COMMIT worked, but
> ABORTng Trans1 will rollback to the original value, no?
Trans2's commit did work, and it never did influence Trans1. And even if
it did, no matter because Trans1 never happened.
In this kind of application of course you would want to use SERIALIZABLE
instead--and that deals with paradoxes by failing the COMMIT.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2004-01-29 18:02:12|
|Subject: Re: msg translation into sk_SK, Docs: SGML -> XML|
|Previous:||From: Marc G. Fournier||Date: 2004-01-29 17:33:48|
|Subject: Stupid question on Read Committed Isolation Level|