Re: Cascade replication

On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

>> 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.
>

<snip>

> 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

I'm laughing quite hard here... :-)

> 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

Yes please, that makes sense.

>> 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");

...which doesn't explain the situation because we don't know why
SIGUSR2 was sent.

I was thinking of something like this

LOG: requesting walsenders for cascading replication reconnect to
update timeline

but then I ask: Why not simply send a new message type saying "new
timeline id is X" and that way we don't need to restart the connection
at all?

>> It would be possible to have synchronous cascaded replication but that
>> is probably another patch :-)
>
> Yeah, right. You'll try? ;)

I'll wait for a request...

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services