Re: [HACKERS] Database replication... - Mission Critica

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

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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