On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 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?
There is a use case - to determine whether WAL has been replayed "from
the future" relative to the WAL stream and control file you have on
disk. But the rest is true enough.
> 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.
All right, well, I've said my piece. I don't have anything to add to
that that isn't sheer repetition. My vote is to hold off on this
until we've talked about replication identifiers and other related
topics in more depth. But if that position doesn't garner majority
support ... so be it!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
