From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The way to know whether the standby has caught up with the master |
Date: | 2011-05-25 06:11:20 |
Message-ID: | BANLkTimARgeq4Sn3OF4LOotmOY5HRXRhaw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 25, 2011 at 12:28 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, May 25, 2011 at 2:16 PM, Heikki Linnakangas
>>>
>>> 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.
>
then, you also need to transmit to the standby if it is the current
sync standby.
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Helmberger | 2011-05-25 06:56:01 | Re: pg_class reltuples/relpages not updated by autovacuum/vacuum |
Previous Message | Fujii Masao | 2011-05-25 05:28:26 | Re: The way to know whether the standby has caught up with the master |