On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
