> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
