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:
I want walreceiver to use fdatasync instead of fsync for performance
improvement. And other DBA might want to choose another method.
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?
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2009-09-19 15:42:53|
|Subject: Re: Schedule for 8.5 Development|
|Previous:||From: Andrew Dunstan||Date: 2009-09-19 05:57:36|
|Subject: Re: [COMMITTERS] pgsql: Easier to translate psql help Instead
of requiring translators|