Re: Synch Rep: direct transfer of WAL file from the primary to the standby

Hi,

On Tue, Jun 16, 2009 at 3:13 PM, Fujii Masao<masao.fujii@gmail.com> wrote:
> The main part of this capability is the new function to read the specified
> WAL file. The following is the definition of it.
>
>    pg_read_xlogfile (filename text [, restore bool]) returns setof bytea
>
>    - filename: name of file to read
>    - restore: indicates whether to try to restore the file from the archive
>
>    - returns the content of the specified file
>      (max size of one row is 8KB, i.e. this function returns 2,048 rows when
>       WAL file whose size is 16MB is requested.)
>
> If restore=true, this function tries to retrieve the file from the
> archive at first.
> This requires restore_command which needs to be specified in postgresql.conf.

In order for the primary server (ie. a normal backend) to read an archived file,
restore_command needs to be specified in also postgresql.conf. In this case,
how should we handle restore_command in recovery.conf?

1) Delete restore_command from recovery.conf. In this case, an user has to   specify it in postgresql.conf instead of
recovery.confwhen doing PITR.   This is simple, but tempts me to merge two configuration files. I'm not sure   why the
parametersfor recovery should be set apart from postgresql.conf. 

2) Leave restore_command in recovery.conf; it can be set in both or either of   two configuration files. We put
recovery.confbefore postgresql.conf only   during recovery if it's in both. After recovery, we prioritize 
postgresql.conf.   In this case, recovery.conf also needs to be re-read during recovery when   SIGHUP arrives. This
mightbe complicated for an user. 

3) Separate restore_command into two parameters. For example,   - normal_restore_command: is used by a normal backend
-recovery_restore_command: is used by startup process for PITR   In this case, it's bothersome that the same command
mustbe set in both of   two configuration files. 

I'm leaning to 1) that restore_command is simply moved from recovery.conf
to postgresql.conf. What's your opinion?

Regards,

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