Re: Cascade replication

On Tue, Jul 5, 2011 at 8:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Now for the rest of the review...

Thanks!

> I'd rather not include another chunk of code related to
> wal_keep_segments. The existing code in CreateCheckPoint() should be
> refactored so that we call the same code from both CreateCheckPoint()
> and CreateRestartPoint().

This makes sense. Will do.

> IMHO it's time to get rid of RECOVERYXLOG as an initial target for
> de-archived files. That made sense once, but now we have streaming it
> makes more sense for us to de-archive straight onto the correct file
> name and let the file be cleaned up later. So de-archiving it and then
> copying to the new location doesn't seem the right thing to do
> (especially not to copy rather than rename). RECOVERYXLOG allowed us
> to de-archive the file without removing a pre-existing file, so we
> must handle that still - the current patch would fail if a
> pre-existing WAL file were there.

You mean that we must keep a pre-existing file? If so, why do we need to
do that? Since it's older than an archived file, it seems to be OK to overwrite
it with an archived file. Or is there corner case that an archived file is older
than a pre-existing one?

If we don't need to keep a pre-existing file, I'll change the way to de-archive
according to your suggestion, as follows;

1. Rename a pre-existing file to EXISTINGXLOG
2. De-archive the file onto the correct name
3. If the de-archived file is invalid (i.e., its size is not 16MB),
remove it and  rename EXISTINGXLOG to the correct name
4. If the de-archived file is valid, remove EXISTINGXLOG
5. Replay the file with the correct name

Or

1. De-archive the file to RECOVERYXLOG
2. If RECOVERYXLOG is valid, remove a pre-existing one and rename   RECOVERYXLOG to the correct name
3. Replay the file with the correct name

> Those changes will make this code cleaner for the long term.
>
> I don't think we should simply shutdown a WALSender when we startup.
> That is indistinguishable from a failure, which is going to be very
> worrying if we do a switchover. Is there another way to do this? Or if
> not, at least a log message to explain it was normal that we requested
> this.

What about outputing something like the following message in that case?
   if ("walsender receives SIGUSR2")       ereport(LOG, "terminating walsender process due to
administrator command");

> It would be possible to have synchronous cascaded replication but that
> is probably another patch :-)

Yeah, right. You'll try? ;)

Regards,

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