Re: replication

From: Bruce Guenter <bruceg(at)em(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: replication
Date: 2000-09-22 16:08:06
Message-ID: 20000922100806.A1676@em.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Sep 22, 2000 at 12:03:13PM -0400, Tom Lane wrote:
> Bruce Guenter <bruceg(at)em(dot)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).

Cool! I'll take a look.

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

Or multiple gateways, one "near" each database server, that try to keep
some synchronization with each other.

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

Oh, definitely agreed. OIDs go out the window, unless both servers have
have identical queries delivered to them at all times. This is rather
difficult to guarantee.
--
Bruce Guenter <bruceg(at)em(dot)ca> http://em.ca/~bruceg/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Aggarwal , Ajay 2000-09-22 16:21:40 what if PQexec() result is toooooo big?
Previous Message Tom Lane 2000-09-22 16:05:45 Re: problem with calling c functions