On Wed, Jul 6, 2011 at 2:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> 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.
Will do.
>>> 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
Looks better than my proposal.
> 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?
Yeah, that's very useful. But I'd like to implement that as a separate patch.
I'm thinking that in that case walsender should send the timeline history file
and walreceiver should write it down to the disk, instead of just sending
timeline ID. Otherwise, when the standby in receive side restarts, it cannot
calculate the latest timeline ID correctly.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center