* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/12/17 1:40 PM, Stephen Frost wrote: > > I just don't buy this argument, at all. These functions names are > > certainly not the only things we're changing with PG10 and serious > > monitoring/backup/administration tools are almost certainly going to > > have quite a bit to adjust to with the new release, and that isn't news > > to anyone who works with PG. > > I in turn don't buy this argument. ;-) > > I have checked a variety of WAL-related monitoring scripts, > graphing/trending scripts, switchover/failover scripts, and the like, > and of course they all make ample use of a variety of *xlog* functions, > but as far as I can tell, they don't care about the pg_xlog renaming and > would continue to work just fine if the functions were not renamed.
The point I was making was that serious montioring systems would have to be changed and I stand by that. Sure, there are simple scripts out there that could, individually, continue to work fine using the old function names (unless and until we change some behavior of those- which I'm sure will end up happening at some point), but the argument being presented is that we shouldn't make people have to change and the only way to do that would be to revert the pg_xlog -> pg_wal change. Anything beyond that and we're into arguing about how *much* we should ask people to change, and for my 2c, that's barely even useful to discuss because once they have to make any change at all then the question will come up if it's "worth it" to move to the next version or the complaint about PG being too difficult to live with will be raised. I'm not terribly worried about such arguments because, put simply, PG10 is going to have enough awesome features that it's an easy question to answer. The argument being presented here is that users won't mind that we changed the name of a critical directory for every PG system in existence, but they're going to be upset that we change a few function names to go along with that change. Really? Certainly, check_postgres is going to have to be changed to address this and, unsurprisingly, it's already had to address a variety of major version differences that have been introduced over the years. Thanks! Stephen
Description: Digital signature