Feature Request for 7.5

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

Responses

Browse pgsql-general by date

  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)