From: | "Chris Travers" <chris(at)travelamericas(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Feature Request for 7.5 |
Date: | 2003-12-01 14:42:39 |
Message-ID: | 00a601c3b821$432f22e0$1a44053d@SAMUEL |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi all;
I have been looking into how to ensure that synchronous replication, etc.
could best be implimented. To date, I see only two options: incorporate
the replication code into the database backend or have a separate "proxy"
which handles the replication.
The main problem with incorporating the system into the backend process is
that it limits the development to the 10-month timeframe between releases.
The main advantage is that the planner could be used to spot queries which
alter tuples and thus could "sort out" select queries. I am not sure if
this could be done using a proxy approach if rules or user-defined functions
were used.
Also the proxy approach could be more flexible in that it could allow for
different types of communications such as IP sharing which may not be
desireable in the database backend.
The easiest way of furthering the development of asynchronous replication
proxies would be to break off the server-side network protocol handler into
a library which would contain functions to bind to ports, listen, and pass
messages back to the calling program. The library could then also be
installed, but also be redistributable, so that developers could build these
solutions.
Also, if the protocol does not provide for "select" queries providing
notification of affected tuples, an extension to handle that would be
helpful and would allow for better load-ballancing.
Best Wishes,
Chris Travers
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-12-01 14:43:45 | Re: pam authentication for postgres |
Previous Message | Craig O'Shannessy | 2003-12-01 14:13:50 | Re: Humor me: Postgresql vs. MySql (esp. licensing) |