Re: [PATCH] Patch to compute Max LSN of Data Pages

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>
Cc: "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Patch to compute Max LSN of Data Pages
Date: 2012-11-14 15:55:45
Message-ID: 022e01cdc280$82d2ade0$887809a0$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, November 14, 2012 9:12 PM Fujii Masao wrote:
> On Wed, Nov 14, 2012 at 5:35 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
> wrote:
> > On Tuesday, November 13, 2012 10:17 PM Fujii Masao wrote:
> >> On Tue, Nov 13, 2012 at 1:23 PM, Amit kapila <amit(dot)kapila(at)huawei(dot)com>
> >> wrote:
> >> > On Monday, November 12, 2012 9:56 PM Alvaro Herrera wrote:
> >> > Robert Haas escribió:
> >> >> On Tue, Jul 31, 2012 at 8:09 AM, Amit kapila
> <amit(dot)kapila(at)huawei(dot)com>
> >> wrote:
> >> >
> >> >>> >> I think I can see all of those things being potentially
> useful.
> >> There
> >> >>> >> are a couple of pending patches that will revise the WAL
> format
> >
> >> >>> I wonder if we shouldn't make this a separate utility, rather
> than
> >> >>> something that is part of pg_resetxlog. Anyone have a thought on
> >> that
> >> >>> topic?
> >> >
> >> >> That thought did cross my mind too.
> >> >
> >> We might be able to use this utility to decide whether we need to
> take
> >> a fresh backup from the master onto the standby, to start old master
> >> as new standby after failover.
> >>
> >> When starting new standby after failover, any data page in the
> standby
> >> must
> >> not precede the master. Otherwise, the standby cannot catch up with
> the
> >> master
> >> consistently. But, the master might write the data page corresponding
> to
> >> the WAL which has not been replicated to the standby yet. So, if
> >> failover happens
> >> before that WAL has been replicated, the data page in old master
> would
> >> precede
> >> new master (i.e., old standby), and in this case the backup is
> required.
> >> OTOH,
> >> if maximum LSN in data page in the standby is less than the master,
> the
> >> backup
> >> is not required.
> >
> > When new standby will start the replication (RequestXLogStreaming()),
> it
> > will
> > send the startpoint, so won't in above scenario that startpoint will
> be
> > ahead of new master
> > (or new master won't have that LSN) and replication will not be
> > eastablished?
>
> The startpoint is the heading LSN of the WAL file including the latest
> checkpoint record. Yes, there can be the case where the startpoint is
> ahead of new master. In this case, replication would fail to be
> established
> because of lack of requested WAL file.

Now user can use this utility to decide if new-standby has max LSN greater
than max LSN of new-master he needs to use fullback-up on new-standby. Is my
understanding right?

>OTOH, there can be the case
> where new master has already been ahead of the startpoint.

But in this case, there is no need for this utility. Right?

> > So now user may not be able to decide whether he needs to do
> incremental or
> > full backup from new master,
> > is this the case you are trying to point?
>
> Sorry, I could not parse this comment. Could you elaborate your concern
> again?

I wanted to understand the usecase mentioned by you for this utility.
As far as I can understand is that it will be used to decide that on
new-standby (old-master) whether a full backup is needed from
New-master(old-standby).
And that situation can occur when new-standby has startpoint LSN greater
than new-master?

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-11-14 15:55:51 Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Previous Message Fujii Masao 2012-11-14 15:52:59 Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY