On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> >> I can clearly understand the utility of being able to reset the system
> >> >> ID to a new, randomly-generated system ID - but giving the user the
> >> >> ability to set a particular value of their own choosing seems like a
> >> >> pretty sharp tool. What is the use case for that?
> >
> > I've previously hacked this up adhoc during data recovery when I needed
> > to make another cluster similar enough that I could replay WAL.
> >
> > Another usecase is to mark a database as independent from its
> > origin. Imagine a database that gets sharded across several
> > servers. It's not uncommon to do that by initially basebackup'ing the
> > database to several nodes and then use them separately from
> > thereon. It's quite useful to actually mark them as being
> > distinct. Especially as several of them right now would end up with the
> > same timeline id...
>
> Sure, but that only requires being able to reset the ID randomly, not
> to a particular value.
I can definitely see a point in a version of the option that generates
the id randomly. But the use case one up actually does require setting
it to a s specific value...
> > Uh. Right now this patch has been written because it's needed for a out
> > of core replication solution. That's what BDR is at this point. The
> > patch is unobtrusive, has other usecases than just our internal one and
> > doesn't make pg_resetxlog even more dangerous than it already is. I
> > don't see much problem with considering it on it's own cost/benefit?
>
> Well, I think it *does* make pg_resetxlog more dangerous; see previous
> discussion of pg_computemaxlsn.
Wasn't the thing around pg_computemaxlsn that there's actually no case
where it could be used safely? And that experienced people suggested to
use it an unsafe fashion?
I don't see how the proposed ability makes it more dangerous. It
*already* has the ability to reset the timelineid. That's the case where
users are much more likely to think about resetting it because that's
much more plausible than taking a unrelated cluster and resetting its
sysid, timeline and LSN.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
