Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Mon, Jan 22, 2007 at 10:45:04PM +0100, Andreas Kostyrka wrote:
>> Now, to replay these statemens correctly on a second DB server, you
>> need to make sure that the second clients insers happen in absolutly
>> the same relative timings. Oh, did I mention, that you need to make
>> sure that the PG backends do have the same priorities and DO really
>> process these statements in the same sequence?
>
> The latter thing turns out to be important, note.  This is also why,
> so far, nobody has a clue how you might get something like Postgres-R
> running under READ COMMITTED mode; indeed, I've heard people say that
> it's impossible.

On the flip side of this, I'd love to see a decent example of this,
where someone, say, constructs a script that spawns several
connections that submit queries that can consistently exercise this
scenario.

It sort of looks as if people that imagine they're building
replication systems don't even imagine that this scenario could exist.

It would be really nice if we could say: "Here's a script that goes
off and spawns 6 psql sessions to perform a dozen or so SQL
statements.  If you do any sort of naive query copying, the data in
the table at the end will visibly differ between master and slave."

With a few sleep statements strategically placed, it surely shouldn't
be too difficult to get READ COMMITTED to break down.

And I think that would be a useful demonstration.  "See?  This little
script, which fits on a single sheet of paper, and which has no
baroque SQL constructions, breaks your replication system."
-- 
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)