Re: Architecture of walreceiver (Streaming Replication)

> Recently, the development of SR is not progressing because of
> the indecision on whether walreceiver should be a subprocess
> of the startup process (i.e., a stand-alone program), or of
> postmaster. Since time is running out, I'd like to discuss
> about this and advance the project.
> 
> The related threads are:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01101.php
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01291.php
> 
> IMO, walreceiver should be a subprocess of postmaster for
> the following reasons.
> 
> 1. It's not easy to give a GUC parameter to a stand-alone
>    walreceiver program. A simple approach is giving a
>    parameter as a command-line argument. But this wouldn't
>    cover a reload of parameter.
> 
> 2. It's not easy to treat the log messages generated by
>    a stand-alone walreceiver as well as the other postgres
>    messages. A straightforward approach is that the startup
>    process passes along the messages to the logger process.
>    But this is not simple.
> 
> I agree that a stand-alone walreceiver is useful for some
> cases. But I think that it's sufficient to provide that as
> contrib or pgfoundry tool. Not need to provide that in core.
> The communication interface to walsender is going to be
> provided as libpq, so it's not difficult to implement such
> a stand-alone tool.

+1. I agree with the idea walreceiver runs as subprocess of
postmaster.
--
Tatsuo Ishii
SRA OSS, Inc. Japan