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
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 |
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 ? |
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 |