Re: Future In-Core Replication

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Future In-Core Replication
Date: 2012-04-30 20:35:02
Message-ID: 4F9EB12602000025000475EB@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> The other half of the changes - applying the updates - is
> relatively straightforward, and it wouldn't bother me to leave
> that in user-land, especially in the MMR case, where you have to
> deal with conflict resolution rules that may be much simpler to
> express in a higher-level language than they would be in C.

I've developed successful MMR more than once, and while I wouldn't
say it's exactly been implemented in the database, it hasn't exactly
been in application space either. The most successful
implementations I've worked with have been a layer just outside the
database, of which application software was completely unaware. The
database wasn't aware of the coordination per se; but it *did* need
to provide transaction information in a clean way, and the
declarations of how data was distributed were in the database. In
my experience a declarative definition of data distribution has
always been sufficient, and certainly cleaner to deal with than
imperative coding would be.

YMMV.

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2012-04-30 21:35:04 Re: Future In-Core Replication
Previous Message Bruce Momjian 2012-04-30 20:13:38 Re: Future In-Core Replication