On Wed, May 25, 2011 at 2:16 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 25.05.2011 07:42, Fujii Masao wrote:
>>
>> For reliable high-availability, when the master crashes, the clusterware
>> must
>> know whether it can promote the standby safely without any data loss,
>> before actually promoting it. IOW, it must know whether the standby has
>> already caught up with the primary. Otherwise, failover might cause data
>> loss.
>> We can know that from pg_stat_replication on the master. But the problem
>> is that pg_stat_replication is not available since the master is not
>> running at
>> that moment. So that info should be available also on the standby.
>>
>> To achieve that, I'm thinking to change walsender so that, when the
>> standby
>> has caught up with the master, it sends back the message indicating that
>> to
>> the standby. And I'm thinking to add new function (or view like
>> pg_stat_replication)
>> available on the standby, which shows that info.
>
> By the time the standby has received that message, it might not be caught-up
> anymore because new WAL might've been generated in the master already.
Right. But, thanks to sync rep, until such a new WAL has been replicated to
the standby, the commit of transaction is not visible to the client. So, even if
there are some WAL not replicated to the standby, the clusterware can promote
the standby safely without any data loss (to the client point of view), I think.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center