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@xxxxxxxxxxxxxxx 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
