Re: walreceiver settings Re: Streaming Replication patch for CommitFest 2009-09

Hi,

On Mon, Sep 21, 2009 at 1:55 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> The startup process could capture stderr from walreceiver and forward it
> with elog(LOG).

The startup process should obtain also the message level in some way
(pipe?), and control the messages according to it. It's confusing that
every messages are output with LOG level.

> The startup process could kill and restart walreceiver to reload. If
> reloading is really required, that is.

I think that it's confusing that SIGHUP kills a process. If walreceiver is
being monitored, the monitoring tool might raise a false alert.

> Which GUC parameters are we
> concerned about? The ones related to logging you mentioned, but if we
> handle logging via a pipe to the startup process, that won't be an issue.

wal_sync_method and fsync. At least I'd like to use fdatasync instead of
fsync for performance improvement.

> Sounds complicated..
>
> One option that you might well want to change on the fly is the
> connection info string in recovery.conf. Neither of the above really
> cater for that, unless we make walreceiver read recovery.conf as well. I
> think we should keep walreceiver quite dumb.

Agreed.

>> 4) Change walreceiver back to a child process of postmaster.
>
> Yeah, that's not out of the question either.

I like this simplest approach. But, as you pointed out, in the original
patch, the way to launch walreceiver is not robust. We need to add
some codes using examples from autovacuum launcher and worker.

Regards,

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