Re: Replication Ideas

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replication Ideas
Date: 2003-08-27 08:12:31
Message-ID: 1061971951.18060.357.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-performance

On Tue, 2003-08-26 at 22:37, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > If you can detect if outside transactions conflict with your
> > transaction, you should be able to determine if the outside transactions
> > conflict with each other.
>
> Uh ... not necessarily. That amounts to assuming that every xact has
> complete knowledge of the actions of every other, which is an assumption
> I'd rather not make. Detecting that what you've done conflicts with
> someone else is one thing, detecting that party B has conflicted with
> party C is another league entirely.

Maybe some sort of Lock Manager? A process running on each node
keeps a tree structure of all locks, requested locks, what is
(requested to be) locked, and the type of lock. If you are running
multi-master replication, each LM keeps in sync with each other,
thus creating a Distributed Lock Manager. (This would also be the
key to implementing database clusters. Of course, the interface
to the DLM would have to be pretty deep within Postgres itself...)

Using a DLM, the postmaster on node_a would know that the postmaster
on node_b has just locked a certain set of tuples and index keys,
and
(1) will queue up it's request to lock that data into that node's
LM,
(2) which will propagate it to the other nodes,
(3) then when the node_a postmaster executes the COMMIT WORK, the
node_b postmaster can obtain it's desired locks.
(4) If the postmaster on node_[ac-z] needs to lock the that same
data, it will then similarly queue up to wait until the node_b
postmaster executes it's COMMIT WORK.

Notes:
a) this is, of course, not *sufficient* for multi-master
b) yes, you need a fast, low latency network for the DLM chatter.

This is a tried and true method of synchronization. DEC Rdb/VMS
has been using it for 19 years as the underpinnings of it's cluster
technology, and Oracle licensed it from them (well, really Compaq)
for it's 9i RAC.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA

"The UN couldn't break up a cookie fight in a Brownie meeting."
Larry Miller

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Csaba Nagy 2003-08-27 08:43:31 Re: pgplsql - Oracle nvl
Previous Message Christian Traber 2003-08-27 07:58:00 pgplsql - Oracle nvl

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2003-08-27 08:22:09 Re: set constraints docs page
Previous Message Kevin Brown 2003-08-27 08:04:19 Re: Date input changed in 7.4 ?

Browse pgsql-performance by date

  From Date Subject
Next Message Tomka Gergely 2003-08-27 08:56:41 Re: 8 way Intel Xeon system
Previous Message Shridhar Daithankar 2003-08-27 07:00:33 Re: 8 way Intel Xeon system