Skip site navigation (1) Skip section navigation (2)

Re: Reliable and fast money transaction design

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Reliable and fast money transaction design
Date: 2007-08-30 18:21:56
Message-ID: 6247.1188498116@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> I think there's a reason why SERIALIZABLE could be slower, and that
> is that it's waiting on possibly-conflicting (but not actually
> conflicting) commits to happen in READ COMMITTED mode.  No?  Won't it
> have to check those things when it COMMITs?

SERIALIZABLE mode does not introduce any waits that wouldn't happen
anyway.  It only affects what happens after you stop waiting.  The
sequence is that if you go to update or delete a row, and you see
there's already an uncommitted change on the row, you have to wait
for that transaction to commit or roll back.  If it rolls back,
you can proceed.  If it commits, then either throw an error (in
SERIALIZABLE mode) or attempt to update/delete the newest tuple
version (in READ COMMITTED mode).

			regards, tom lane

In response to

Responses

pgsql-general by date

Next:From: Andrew SullivanDate: 2007-08-30 18:28:03
Subject: Re: date of next Version 8.2 release
Previous:From: Andrew SullivanDate: 2007-08-30 18:20:18
Subject: Re: PostgreSQL.Org (was: PostgreSQL Conference Fall 2007)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group