Re: Architecture of walreceiver (Streaming Replication) - Mailing list pgsql-hackers

From Euler Taveira de Oliveira
Subject Re: Architecture of walreceiver (Streaming Replication)
Date
Msg-id 4AEEF75C.8060605@timbira.com
Whole thread Raw
In response to Architecture of walreceiver (Streaming Replication)  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Architecture of walreceiver (Streaming Replication)
Re: Architecture of walreceiver (Streaming Replication)
List 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/


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: libpq - extending PQexecParams/PQexecPrepared to specify resultFormat for individual result columns
Next
From: Robert Haas
Date:
Subject: Re: Architecture of walreceiver (Streaming Replication)