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(dot)fujii(at)gmail(dot)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.conf when doing PITR.
This is simple, but tempts me to merge two configuration files. I'm not sure
why the parameters for 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.conf before 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 might be 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 must be 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