Feature Request for 7.5

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Feature Request for 7.5
Дата
Msg-id 00a601c3b821$432f22e0$1a44053d@SAMUEL
обсуждение исходный текст
Ответы Re: Feature Request for 7.5  (Peter Eisentraut <peter_e@gmx.net>)
Re: Feature Request for 7.5  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: "B. van Ouwerkerk"
Дата:
Сообщение: Re: PostgreSQL from a newcomers perspective
Следующее
От: Barbara Lindsey
Дата:
Сообщение: Re: Pg module for Perl