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
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 |