Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Andres,

* Andres Freund (andres@anarazel.de) wrote:
> On 2017-01-04 09:38:42 -0500, Stephen Frost wrote:
> > * Andres Freund (andres@anarazel.de) wrote:
> > > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > > > * Vladimir Rusinov (vrusinov@google.com) wrote:
> > > > > I think I +1 on this.
> > > > > I've did a github search on these function names and there is a lot of code
> > > > > that use them. E.g. there is 8.5k hits for pg_last_xlog_location
> > > > > <https://github.com/search?q=pg_last_xlog_replay_location&type=Code&utf8=%E2%9C%93>;
> > > > > a lot of them a forks and copy-pastes, but still, that's quite a lot. Let's
> > > > > keep the aliases around for couple of versions after which hopefully a lot
> > > > > of the code will be updated.
> > > >
> > > > And there's 12k hits for pg_xlog.
> > >
> > > > If we do that, we'll just end up with exactly the same question about
> > > > removing them and the same amount of code breakage in a few years.  I
> > > > don't see how that is really helping anyone.
> > >
> > > Meh^2.  The cost of having pg_xlog was that people lost their
> > > data. Hence their was motivation of changing things. The cost of having
> > > some function aliases is, what, a pg_proc line?  If we end up carrying
> > > them forever, so what?
> >
> > I outlined exactly that in the part you didn't quote.
>
> Sure, but my point was that you and several others essentially argue for
> breaking things gratuitously. And I think that's bad. That you can live
> with backward compatibility doesn't change that point.

I do not agree that we are arguing for breaking things gratuitously.
That's saying that there's no justification for such a change and I
think that's wrong- the prior names were driven off the directory name
and were, really, not well suited to what the functions were actually
for.  This change is to align the functions with the agreed-upon
directory name change and because the new name is distinctly more
accurate than the prior name.  As discussed previously, the term
'transaction log' is more closely related to what *clog* is than the
write-ahead log.

My feeling is that people who are arguing for the aliases are doing so
from a position of "it's easy for us to do, so we should," which I am
generally not in favor of when it comes to backwards compatibility
because it leaves things in an inconsistent state.  Tools which monitor
the progression of our write-ahead-log (wal) from the primary to stanbys
will end up using a function that has "xlog" in the name, even though
that's an inconsistent and less than accurate name for what they're
actually doing, simply because "well, that part didn't break, so we
don't have to change it, even though these other things had to be
changed to refer to 'wal'".  That, in my opinion, isn't the right
compromise to be making.

> > > > If we really feel that this is the only thing between 9.6 and 10 that'll
> > > > cause problems for some serious amount of code and we don't expect to
> > > > change the function APIs anytime in the near future then perhaps we
> > > > could keep aliases, *document* them, and treat them as full functions
> > > > just like the regular ones.
> > >
> > > I think we've been far to cavalier lately about unnecessarily breaking
> > > admin and monitoring tools. There's been pg_stat_activity backward
> > > incompat changes in most of the last releases. It's a *PAIN* to develop
> > > monitoring / admin tools that work with a number of releases.  It's fine
> > > to cause that pain if there's some considerable benefit (e.g. not
> > > triggering data loss seems like a case for that, as imo is unifying
> > > configuration), but I don't see how that justifying breaking things
> > > gratuitously.  Just renaming well known functions for a minor bit of
> > > cleanliness seems not to survive a cost/benefit analysis.
> >
> > I agree that we have been breaking monitoring tools on the regular for a
> > while as we continue to add capabilities and improve things, which is
> > part of the reason that I don't see this particular break as a very big
> > deal- serious monitoring tools are going to need to be updated anyway.
>
> I have no problem with breaking things when necessary. I do have a
> problem when we do so willy-nilly when providing backward-compatibility
> would have been easy enough. E.g. Nearly all recent pg_stat_activity
> changes would have been doable just as well without breakage.

Would those changes have resulted in an inconsistent and difficult
system to understand and follow?  For pg_stat_activity, frankly, I don't
recall offhand which probably means they weren't a very big deal for me.

Changes to anything related to the 'pg_xlog' directory or the set of
functions that pgbackrest or our tools care about are a lot closer to me
and changes there represent serious time that I'll need to ask David and
Jeff to spend on updating pgbackrest and our tooling for, yet I've had
no push-back from them on this because there is general agreement that
this is a good change to be making.

> > I don't see that changing any time soon either- we are woefully far
> > behind in this area compared to other databases and we should be trying
> > to encourage people to continue improving these areas, not making things
> > unnecessairly difficult by requiring backwards compatibility hacks.
>
> By breaking stuff on a regular basis we're also showing that we're
> behind. Compatibility also is a big topic. We also force users to stay
> behind longer, and to upgrade less frequently.

I don't mind showing that we're behind, it's a fact and anyone who cares
to will found that out quickly enough.  I do object to putting up
roadblocks or making it more difficult than necessary to making
progress.

I have a pretty hard time believing that users are going to seriously
stay on older versions for very much longer just because of these
changes.  Either they have a strong interest in the new features in
later releases and have cause to upgrade, in which case updating a few
function calls isn't going to be a big deal, or they don't have much
cause to change and therefore they're not going to rush to do so (which
is an entirly acceptable position!).

Lastly, if they have an issue with the tooling around the database that
uses these functions or they have an issue with the maintenance
requirements associated with such relativly mundane changes, that they
instead use tools which are well maintained and are updated consistently
with the changes being made.

Thanks!

Stephen