Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit

From: Steven Singer <ssinger(at)navtechinc(dot)com>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
Date: 2003-04-12 19:46:28
Message-ID: Pine.LNX.4.33.0304121939330.16736-100000@pcNavYkfAdm1.ykf.navtechinc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>
> Does it matter if transactions that do not affect each other are committed
> on the slave in a different order than they were on the master? I don't
> think that's guaranteed by the above (unless the inserts into
> replication_queue were deferred to transaction end), but I'm also
> uncertain if it's a constraint you're concerned with.

Well it all depends on what you mean by "Does not accect each other". Do
2 transactions not affect each other if they touch different rows,tables,
or deal with data that is unrelated from the point of view of an
application query the database.

Consider the following transactions on the master
T1: Insert DeptId=1 INTO Department
T2: Insert EmpId=1,DeptId=1 INTO Employee

Those 2 transactions update different tables but if T2 is sent to slaves
before T2 then A) You might have foreign key violations and B) Even if you
don't have foreign keys someone querying the slave will see a database
that never existed(at any point in time) on the master.

But if you to ensuer that T1 and T2 are sent to the slave in the same
transaction(and you defered any constraint checks to the end of your
combined transaction) you wouldn't have this problem but if the two
transactions where to update the same row then the order would be
important and you would still need your code to deal with this case.

--
Steven Singer ssinger(at)navtechinc(dot)com
Dispatch Systems Phone: 519-747-1170 ext 282
Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steven Singer 2003-04-12 20:06:34 Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
Previous Message Michael Paesold 2003-04-12 18:51:36 Re: Backpatch FK changes to 7.3 and 7.2?