Re: pg_resetxlog to clear backup start/end locations. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: pg_resetxlog to clear backup start/end locations.
Date
Msg-id 20140623.182445.257794934.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: pg_resetxlog to clear backup start/end locations.  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pg_resetxlog to clear backup start/end locations.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Hi,

At Mon, 23 Jun 2014 17:10:05 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
<CAHGQGwFy_CDmfURiu6ZOaT2hTQo_eiJAJ7vWEWysOL15ocTAdg@mail.gmail.com>
> > I assume the primary usage of this patch to be, as described
> > before, Dissolving a recovery freezing caused by wrongly placed
> > backup label. Crash recovery has been already done at that time
> > so resetxlog's current behavior seems also fittin the situation,
> > I suppose.
> 
> One question is; is there case where a user wants to reset only
> backup locations? I'm not sure if there are such cases. If they exist,
> probably we should implement new option which resets only backup
> locations. Thought?

As I described as above, I don't see obvious use case where ONLY
backup location is needed to be resetted. The option you proposed
not only clears backup locations but also inhibits resetting xlog
infos which would be done without the option. The behavior would
puzzle users.

> > Ok, I'm doing modify it to reset backup locations by default and
> > remove the new option '-b' to do that. Since this seems looking
> > to be a bug for the poeple, I'll provide backpatches back
> > to... 8.4?  (Final release of 8.4 is scheduled at July 2014)
> 
> I was thinking that we don't need to backpatch this to 8.4 because
> 8.4 doesn't have any backup locations. No?

I'm not so knowledgeable about ancint(?) specs:p Of course this
phrase means "back to 8.4 that this patch has any meaning".

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Next
From: Ashutosh Bapat
Date:
Subject: Re: inherit support for foreign tables