Re: Cascade replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cascade replication
Date: 2011-07-06 08:32:13
Message-ID: CA+U5nM+sZ2ZngGen=BzE7KsRWZ1N-fe53hM5CJuVdyoC1SvVdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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

OK, happy to do that part as an additional patch. That way we can get
this committed soon - in this CF.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2011-07-06 09:31:37 Re: patch: enhanced get diagnostics statement 2
Previous Message Pavel Golub 2011-07-06 07:53:46 Re: fixing PQsetvalue()