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? 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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services