* Peter Eisentraut (peter.eisentraut@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