From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Guenter <bruceg(at)em(dot)ca> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: replication |
Date: | 2000-09-22 16:03:13 |
Message-ID: | 29326.969638593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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).
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
From | Date | Subject | |
---|---|---|---|
Next Message | K Parker | 2000-09-22 16:03:33 | Re: c function |
Previous Message | Bruce Guenter | 2000-09-22 15:31:02 | Re: replication |