Re: Review: Patch to compute Max LSN of Data Pages

On Wednesday, June 26, 2013 1:20 PM Andres Freund wrote:
> On 2013-06-26 08:50:27 +0530, Amit Kapila wrote:
> > On Tuesday, June 25, 2013 11:12 PM Andres Freund wrote:
> > > On 2013-06-16 17:19:49 -0700, Josh Berkus wrote:
> > > > Amit posted a new version of this patch on January 23rd. But
> last
> > > > comment on it by Tom is "not sure everyone wants this".
> > > >
> > > > https://commitfest.postgresql.org/action/patch_view?id=905
> > >
> > > > ... so, what's the status of this patch?
> > >
> > > That comment was referencing a mail of mine - so perhaps I better
> > > explain:
> > >
> > > I think the usecase for this utility isn't big enough to be
> included in
> > > postgres since it really can only help in a very limited
> > > circumstances. And I think it's too likely to be misused for stuff
> it's
> > > not useable for (e.g. remastering).
> > >
> > > The only scenario I see is that somebody deleted/corrupted
> > > pg_controldata. In that scenario the tool is supposed to be used to
> > > find
> > > the biggest lsn used so far so the user then can use pg_resetxlog
> to
> > > set
> > > that as the wal starting point.
> > > But that can be way much easier solved by just setting the LSN to
> > > something very, very high. The database cannot be used for anything
> > > reliable afterwards anyway.
> >
> > One of the main reason this was written was to make server up in case
> of
> > corruption and
> > user can take dump of some useful information if any.
> >
> > By setting LSN very, very high user might loose the information which
> he
> > wants to take dump.
>
> Which information would that loose?
Information from WAL replay which can be more appropriate by selecting
LSN.
Also for a developer, guessing very high LSN might be easy, but for users
it might not be equally easy, and getting such value by utility would be
comfortable.

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.

> We don't currently use the LSN for
> tuple visibility. And you sure wouldn't do anything but dump such a
> cluster.
> Now you could argue that you could modify this to find the current xid
> used - but that's not that easy due to the wraparound semantics of
> xids. And you are more likely to be successfull by looking at pg_clog.

With Regards,
Amit Kapila.