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

Hi,

Thanks for the comment!

On Tue, Jul 7, 2009 at 12:16 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> 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?
>
> I confess to not having paid much attention to this thread so far, but ...
> what is the rationale for having such a capability at all?

If the XLOG files which are required for recovery exist only in the
primary server,
the standby server has to read them in some way. For example, when the latest
XLOG file of the primary server is 09 and the standby server has only 01, the
missing files (02-08) has to be read for recovery by the standby server. In this
case, the XLOG records in 09 or later are shipped to the standby server in real
time by synchronous replication feature.

The problem which I'd like to solve is how to make the standby server read the
XLOG files (XLOG file, backup history file and timeline history) which
exist only
in the primary server. In the previous patch, we had to manually copy those
missing files to the archive of the standby server or use the warm-standby
mechanism. This would decrease the usability of synchronous replication. So,
I proposed one of the solutions which makes the standby server read those
missing files automatically: introducing new function pg_read_xlogfile() which
reads the specified XLOG file.

Is this solution in the right direction? Do you have another
reasonable solution?

> It seems to
> me to be exposing implementation details that we do not need to expose,
> as well as making assumptions that we shouldn't make (like there is
> exactly one archive and the primary server has read access to it).

You mean that one archive is shared between two servers? If so, no.
I attached the picture of the environment which I assume.

Please feel free to comment.

Regards,

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