On 2014-07-01 11:11:12 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > I think it's pretty much a given that pg_resetxlog is a tool that can
> > have disastrous effects if used lightly. If people changes their sysid
> > wrongly, they're not any worse than if they change their multixact
> > counters and start getting failures because the old values stored in
> > data cannot be resolved anymore ("it's already been wrapped around").
> > Or if they remove all the XLOG they have since the latest crash. From
> > that POV, I don't think the objection that "but this can be used to
> > corrupt data!" has any value.
>
> After thinking about this a little more, I guess I don't really think
> it's a bit problem either - so consider my objection withdrawn.
Thanks!
> I am, however, kind of frustrated, still, that the pg_computemaxlsn
> patch, which I thought was rather a good idea, was scuttled by the
> essentially that same objection: let's not extend pg_resetxlog &
> friends because people might use the new functionality to do bad
> things and then blame us.
Well, the reasons were a bit different. Senior community members
repeatedly suggested that it'd be usable for faillback - and it's not a
unreasonable to think it is. Even though it'd fail subtly because of
hint bit and related reasons.
In contrast you have to be pretty desperate to think that you could make
two clusters replicate from each other by just fudging pg_control long
enough, even if the clusters aren't actually related.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
