Skip site navigation (1) Skip section navigation (2)

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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: walreceiver settings Re: Streaming Replication patch for CommitFest 2009-09
Date: 2009-09-19 06:10:39
Message-ID: 3f0b79eb0909182310w738c7ea5ia17b37776a7e927c@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> This approach is OK if the stand-alone walreceiver is treated steadily
> by the startup process like a child process under postmaster:
>
> * Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT...
>   For example, the startup process would need to rethrow walreceiver
>   the interrupt from postmaster.
>
> * Communication with other child processes: stats collector? syslogger?...
>   For example, the log message generated by walreceiver should also
>   be collected by syslogger if requested.

Also we should consider how to give a GUC parameter to the stand-alone
walreceiver. In the initial patch, since walreceiver was a child process of
postmaster, it could easily get any GUC parameter. But it's not so easy
to give a GUC parameter to a stand-alone program.

I think that at least the following parameters should affect walreceiver:

* wal_sync_method
  I want walreceiver to use fdatasync instead of fsync for performance
  improvement. And other DBA might want to choose another method.

* fsync
  I'm not surprised if someone wants to disable fsync in the standby.

* some parameters for logging
  I think that the log messages generated by walreceiver should also be
  treated as well as the other postgres messages. For example, I'd like
  to specify log_line_prefix also for walreceiver.

There are some approaches to give a GUC parameter to walreceiver.
Which is the best?

1) Give a parameter as a command-line argument of the stand-alone
    walreceiver. This is a straightforward approach, but wouldn't cover
    a reload of parameter.

2) Give a parameter via pipe between the startup process and walreceiver.

3) Change walreceiver to read a configuration file. The problem is that
    the command-line argument of postmaster doesn't affect walreceiver.
    The combination of 1) and 3) might be required.

4) Change walreceiver back to a child process of postmaster.

Do you have any other better approach?

Regards,

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

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-09-19 15:42:53
Subject: Re: Schedule for 8.5 Development
Previous:From: Andrew DunstanDate: 2009-09-19 05:57:36
Subject: Re: [COMMITTERS] pgsql: Easier to translate psql help Instead of requiring translators

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group