Re: Replication Ideas - Mailing list pgsql-general

From Ron Johnson
Subject Re: Replication Ideas
Date
Msg-id 1061971951.18060.357.camel@haggis
Whole thread Raw
In response to Replication Ideas  (Chris Travers <chris@travelamericas.com>)
Responses Re: Replication Ideas  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-general
On Tue, 2003-08-26 at 22:37, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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.l.johnson@cox.net
Jefferson, LA USA

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


pgsql-general by date:

Previous
From: Csaba Nagy
Date:
Subject: Re: pgplsql - Oracle nvl
Next
From: Ron Johnson
Date:
Subject: Re: update entire table (with PostGreSQL alone)?