From: "Aaron J. Seigo" <aaron@gtv.ca>
To: Jeff Hoffmann <jeff@propertykey.com>
Subject: Re: [GENERAL] Re: replication
Date: Tue, 16 Nov 1999 11:54:23 -0700
Content-Type: text/plain
References: <Pine.LNX.4.04.9911161628270.8457-100000@tinago.msuiit.edu.ph>
	<99111609264002.18220@stilborne>
	<383192A9.AA3E25C4@propertykey.com>
In-Reply-To: <383192A9.AA3E25C4@propertykey.com>
Cc: pgsql-general@hub.org
MIME-Version: 1.0
Message-Id: <99111612001404.18220@stilborne>
Content-Transfer-Encoding: 8bit

hi...

> my favorite hack is to wrap the c/c++ api so you can set up a group of
> mirror database connections and then calling the wrapped functions will
> call the original function on each of the mirror database connections. 
> i've really never thought of it as something that should be part of the
> library, though, since that's pretty easy to implement in the
> application.

very cool... but i too agree that this shouldn't necessarily be in the
libraries...

this needs to be in the back end... otherwise, if you have multiple people
performing updates on different replicated servers, how can you guarentee
concurancy? how do you manage the differences between read-only and updateable
replicants? (this can be done using your wrapper method, but quickly gets
clumsy)

also, it would make maintaining replication simpler if it were part of the
back end process... and not prone to some app that goes around your wrapped lib
and defeats the replication scheme altogether... imo, it should be part of the
transaction system.... =)

-- 
Aaron J. Seigo
Sys Admin