On Tuesday, June 25, 2013 11:12 PM Andres Freund wrote:
> Hi,
>
> 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.
So I think in such scenario's it can be quite helpful to users, but such
scenarios are rare and so
it might not be a utility which user will need often.
With Regards,
Amit Kapila.
