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