Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Cynthia Shang <cynthia(dot)shang(at)crunchydata(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Vladimir Rusinov <vrusinov(at)google(dot)com>
Subject: Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date: 2016-12-29 17:07:34
Message-ID: 20161229170734.GT18360@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Cynthia,

* Cynthia Shang (cynthia(dot)shang(at)crunchydata(dot)com) wrote:
> 1) I agree with Michael that we should make this change backward compatible. It would help PostgreSQL image if we did not break everyone's code. It costs businesses money to rewrite code (e.g. middle tier software, backup tools, etc), test and redeploy to their customers.

While I agree that we don't want to break client code or to make
backwards incompatible changes without good cause, in this case, it's
definitely a good cause and it makes sense to have things be consistent
and that includes changing these functions.

We make backwards-incompatible changes with each major release, which is
part of why we support older versions of PG for as long as we do- to
give PG users time to make any necessary changes for the new version of
PG. One could argue that we shouldn't ever make a backwards
incompatible change because it will break an existing user's code and
cost users time and effort to rewrite that code, but the flip side of
that is that the extra code and complexity results in its own
maintenance burdens for the code and the project moving forward.

Generally speaking, we've also found that backwards compatibility
'features' end up having a much longer life than they should.
Ultimately, the best way forward tends to be either make the backwards
incompatible change or don't make the change at all. We've already
agreed on this particular change, and with good reason, so the way
forward is to make the rest of the changes, not to go half-way or to try
and provide some backwards compatibility complexity.

> 2) We decided to rename the pg_xlog directory because people were deleting it when disks were getting full thinking it was just unimportant logging data; I get that. I'm a little unclear why we need to change the functions - it would be less painful to our users and less risky if we just left them as is. Could someone please elaborate why this change is necessary? I'm just trying to understand that.

It would be inconsistent to change the directory name without also
changing the documentation, functions, and other user-facing pieces.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cynthia Shang 2016-12-29 17:48:56 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Previous Message Dean Rasheed 2016-12-29 17:04:54 Re: Improving RLS planning