Re: Architecture of walreceiver (Streaming Replication)

On Nov 2, 2009, at 5:06 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> 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.

I agree. A stand-alone tool seems like a good idea (which is why I
proposed it) but I don't think that should mean that we can't have a
tightly integrated core facility. We can decide later whether there it
is helpful for those things to share code; right now, we should focus
on getting an initial version of this feature out the door.

Speaking of getting things out the door, what's up with Hot Standby?
It seemed like the outstanding issues were just about dealt with, and
then the discussion died off...

...Robert