Re: Reliable and fast money transaction design

On Thu, Aug 30, 2007 at 02:21:56PM -0400, Tom Lane wrote:
> SERIALIZABLE mode does not introduce any waits that wouldn't happen
> anyway.  It only affects what happens after you stop waiting.

Ok, this makes me think I'm deeply confused about something.  (Uh,
well, on this specific topic.  Anyone who's ever read any of my posts
or talked to me for 10 seconds will attest that I'm deeply confused
about plenty of things generally!)

I had the impression that, when working in READ COMMITTED mode, you
could see (for instance) _new_ rows that were INSERTed by others who
were also doing work.  In SERIALIZABLE, you couldn't.  So in cases
where the additional rows met criteria in your WHERE clause late in
your transaction, SERIALIZABLE had to throw them away.  For instance,
in READ COMMITTED, in a longish transaction, the "WHERE processed on
IS NULL" might match more rows than were available at the beginning
of the transaction when you SELECTed them, but in SERIALIZABLE, you
can't see those additional rows.  Is that wrong?  (If so, I'm going
to have to spend some time working out clarifications for the manual.)
And doesn't the SERIALIZABLE transaction have to figure out that
"this row doesn't count for me"?

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to.  That actually seems sort of quaint now.
        --J.D. Baldwin