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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
