Re: Review: Patch to compute Max LSN of Data Pages - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Review: Patch to compute Max LSN of Data Pages
Date
Msg-id 008d01ce7300$0a256460$1e702d20$@kapila@huawei.com
Whole thread Raw
In response to Re: Review: Patch to compute Max LSN of Data Pages  ('Andres Freund' <andres@2ndquadrant.com>)
List pgsql-hackers
On Thursday, June 27, 2013 11:26 AM Andres Freund wrote:
> On 2013-06-27 11:16:25 +0530, Amit Kapila wrote:
> > On Wednesday, June 26, 2013 10:19 PM Fujii Masao wrote:
> > > On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila
> <amit.kapila@huawei.com>
> > > >> >   One more use case for which this utility was done is as
> below:
> > > >> >   It will be used to decide that on new-standby (old-master)
> > > whether
> > > >> a full
> > > >> > backup is needed from
> > > >> >   New-master(old-standby).
> > > >> >   The backup is required when the data page in old-master
> precedes
> > > >> >   the last applied LSN in old-standby (i.e., new-master) at
> the
> > > >> moment
> > > >> >   of the failover.
> > > >>
> > > >> That's exactly what I was afraid of. Unless I miss something the
> > > tool
> > > >> is
> > > >> *NOT* sufficient to do this.
> > > >
> > > > You mean to say if user knows the max LSN of data pages in old-
> master
> > > and
> > > > last applied LSN in new master, he cannot decide whether
> > > > Full backup is needed? It should be straightforward decision that
> > > skip a
> > > > backup if that old-master LSN is less than the new-master (i.e.,
> last
> > > > applied LSN, IOW, timeline switch LSN).
> > > > It was proposed as a usecase in this below mail:
> > > > http://www.postgresql.org/message-id/CAHGQGwHyd1fY0hF0qKh0-uKDh-
> > > gcbYxMOFBYVk
> > > > Kh4jzji-FCfg@mail.gmail.com
> > >
> > > I guess he meant the commit hint bit problem.
> >
> > True, after reading the thread mentioned by Andres, I got the reason
> he was
> > pointing why it is not sufficient.
> > So can it be useful if database has checksums enabled?
> 
> I think for that usecase its far more useful to work on getting
> pg_rewind since that has a chance of working when local WAL has been
> applied that hadn't yet shipped to the other side (which is frequently
> the case).

Aren't the use case for both is bit different
Pg_computmaxlsn - by computing max lsn for checksums enabled database, user
can made old-master follow new-master if maxlsn suggests that fullbackup is                  not required.

Pg_rewind       - a tool to resynchronize old-master and new-master by
copying changed blocks from new master.                 I think more work might be needed in case DDL's happened
on old-master after forking of new-master.

Although for this case, both have resemblance in terms of avoiding full
backup, but I think maxlsn tool can be independently also used.
Do you think pg_rewind can be used by default for any checksum enabled
database to resynchronize old-master?

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_filedump 9.3: checksums (and a few other fixes)
Next
From: Peter Geoghegan
Date:
Subject: Re: pg_filedump 9.3: checksums (and a few other fixes)