Hi,
On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao <masao.fu...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
