From: | <darren(at)up(dot)hrcoxmail(dot)com> |
---|---|
To: | shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Database replication... - Mission Critica |
Date: | 2002-11-07 16:15:38 |
Message-ID: | 20021107161538.JNEX1349.lakecmmtao02.coxmail.com@lakecmmtab02 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> > This is wrong assumption. If
> >
> > 1st client executes UPDATE t SET a = 1 WHERE b = 2;
> > 2nd client executes UPDATE t SET a = 2 WHERE b = 2;
> >
> > at "the same time" you don't know in what order these
> > queries will be executed on two different servers (because
> > you can't control what transaction will lock record(s)
> > for update first).
>
> I guess we would need two phase commit in this case. Then it could be
> guaranteed.
>
I'm not sure 2PC would guarantee order here. There is
potential for a dead lock across system boundary in this
example. If the pre commit messages were sent at the same
time which server would lock the resource?
Darren
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2002-11-07 16:16:09 | Re: Q! |
Previous Message | Shridhar Daithankar | 2002-11-07 16:15:23 | Re: comamnds |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-07 16:26:42 | Re: [HACKERS] PostgreSQL supported platform report and a |
Previous Message | Olivier PRENANT | 2002-11-07 16:15:08 | Re: [HACKERS] PostgreSQL supported platform report and a |