To: Bruce Guenter <bruceg@em.ca>
cc: pgsql-general@postgresql.org
Subject: Re: replication 
In-reply-to: <20000922093102.A1715@em.ca> 
References: <001d01c023ca$e37d9cc0$330a0a0a@Adam>
	<39CB1120.DBEC91AB@haneke.de> <20000922093102.A1715@em.ca>
Comments: In-reply-to Bruce Guenter <bruceg@em.ca>
	message dated "Fri, 22 Sep 2000 09:31:02 -0600"
Date: Fri, 22 Sep 2000 12:03:13 -0400
Message-ID: <29326.969638593@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Guenter <bruceg@em.ca> writes:
> I've been thinking that one way to emulate replication would be to run a
> pgsql "shim" that would redirect queries to two back-ends
> simultaneously, creating transactions for update commands, and aborting
> when necessary.  The shim would be a long-running gateway process, that
> could check for data consistency when it started up.  This is all off
> the top of my head, so is this at all a reasonable idea?

Awhile back, someone reported that they were successfully using exactly
this idea.  Check the PG list archives (sorry, I forget which list).

I'm not convinced that this scales real well to multiple concurrent
clients ... at the very least, you'd need a single gateway that
serializes all the requests.  You might still have problems with the
two databases not executing requests in exactly the same order.  Also
it'd be really dangerous to use OIDs as a way of identifying rows in
application queries.  But with a cooperative application it could
probably be made to work.

			regards, tom lane