Re: Architecture of walreceiver (Streaming Replication)

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Architecture of walreceiver (Streaming Replication)
Date: 2009-11-02 15:14:36
Message-ID: 4AEEF75C.8060605@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao escreveu:
> IMO, walreceiver should be a subprocess of postmaster for
> the following reasons.
>
+1. I agree that the first version should be as close as possible to
postmaster. My points are: (i) it will be easier to install (no need to
install another third-party software), (ii) it will be easier to administrate
(the options will be available in one central point -- postgresql.conf), and
(iii) it will be easier to control (it is a postmaster subprocess).

But I see some value if it would be possible to design it in a way that other
third-party softwares could replace it completely (even if it couldn't take
advantage of some postmaster features).

Of course, there is no need to develop such a POC external walreceiver tool.
You just need to have in mind that available interfaces should be accessible
by external tools. If someone decides to code a tool to mimic walreceiver but
with some aditional features such as wal filtering then (s)he is free to do it
because we provide entry points in the API.

BTW, are you going to submit another WIP patch for next commitfest?

--
Euler Taveira de Oliveira
http://www.timbira.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2009-11-02 15:18:59 Re: libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
Previous Message Tom Lane 2009-11-02 14:41:49 Re: Error on compile for Windows