Feature Request for 7.5 - Mailing list pgsql-general

From Chris Travers
Subject Feature Request for 7.5
Date
Msg-id 00a601c3b821$432f22e0$1a44053d@SAMUEL
Whole thread Raw
Responses Re: Feature Request for 7.5
Re: Feature Request for 7.5
List 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


pgsql-general by date:

Previous
From: "B. van Ouwerkerk"
Date:
Subject: Re: PostgreSQL from a newcomers perspective
Next
From: Barbara Lindsey
Date:
Subject: Re: Pg module for Perl