Re: Renaming of pg_xlog and pg_clog - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id CABUevEytvSk141FccG7io-y517NfD3kE_oxG-SUXNan9imTkMg@mail.gmail.com
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Christoph Berg <myon@debian.org>)
Responses Re: Renaming of pg_xlog and pg_clog
List pgsql-hackers


On Fri, Aug 26, 2016 at 12:44 PM, Christoph Berg <myon@debian.org> wrote:
Re: Fujii Masao 2016-08-26 <CAHGQGwHK2yimfLvG_WQ1Vrq2h+CMzgv5u6OEmxr-cbJRO+WKWQ@mail.gmail.com>
> > I agree on a hard break, unless we get pushback from users, and even
> > then, they can create the symlinks themselves.
>
> I strongly prefer symlink approach not to break many existing tools
> and scripts.

Symlinks might actually be worse than removing the directories
altogether. If your backup tool fails because the pg_xlog directory is
gone, you'll hopefully notice, but if you end up with a backup that
consists merely of a copy of a symlink named pg_xlog, you might not
notice.

+1. It's *much* better to cause a clean break. That way people will notice it, and can fix it (and it will be an easy fix).

An unclean break might leave people with things that look like they work, but don't. That's a lot more dangerous.


Same reason I'm also +1 for Stephens suggestion to put all things that should not be in a base backup into the same directory. That may break things now, but it will simplify things down the road. And doing it at the same time as renaming these things makes a lot of sense, because it causes breakage that tool-builders *have* to look at, and then they will hopefully also notice the other change.

--

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Simon Riggs
Date:
Subject: Re: Renaming of pg_xlog and pg_clog