Architecture of walreceiver (Streaming Replication)

Hi,

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.

Thought? Please feel free to comment.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center