Re: Getting to 9.3 beta - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Getting to 9.3 beta
Date
Msg-id 003001ce2ce2$86b60570$94221050$@kapila@huawei.com
Whole thread Raw
In response to Re: Getting to 9.3 beta  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Friday, March 29, 2013 11:04 PM Andres Freund wrote:
> On 2013-03-29 12:28:59 -0400, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote:
> > >> What is a reasonable timeframe to target for completion of these
> items?
> >
> > > Here's my take on it:
> >
> > Thanks for annotating these!  I've commented on the ones where I
> > come to a different conclusion:
> >
> > > - replace plugins directory with GUC
> > >   Peter has agreed to boot it to the next fest afaics
> > >   (515357F4.6000307@gmx.net)
> > >   => move (done)
> >
> > It looks to me more like a RWF situation, since Peter has evidently
> lost
> > interest in committing this feature at all.  So I marked it that way.
> 
> Yea, after a second reading of Peter's email I agree.
> 
> > > - Patch to compute Max LSN of Data Pages:
> > >   I *personally* don't really see a point in including it in
> postgres,
> > >   there doesn't really seem to be any real demand met by the tool
> > >   => reject?
> >
> > Not sure.  It certainly hasn't drawn that much enthusiasm on the
> list,
> > but it strikes me as the sort of thing that when you need it you
> really
> > need it.  It would be interesting to hear opinions about it from
> people
> > who deal with data recovery situations on a regular basis.
> 
> I only have done so infrequently, but I guess my real problem is that I
> can't see it being all that helpful in such a situation. If you've lost
> pg_xlog - otherwise there doesn't seem to be much use in this - you can
> just use
> pg_resetxlog to set an insanely high lsn and then dump & restore the
> database. 

This utility can give user value that is okay to proceed.

> The only reason to use something more complex than this is if
> you want to continue using the cluster which seems like a really bad
> idea.

I agree that mostly user doesn't need to use cluster further, 
but incase if he is aware that only some part of the database (particular
tablespace) has problem
and he can take dump of that part of database and redo some of lost
operations on other tablespaces.


With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Hash Join cost estimates
Next
From: Bruce Momjian
Date:
Subject: Re: Fix for pg_upgrade and invalid indexes