Re: pg_xlog -> pg_xjournal? - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: pg_xlog -> pg_xjournal?
Date
Msg-id 556CBDD1.1090407@agliodbs.com
Whole thread Raw
In response to pg_xlog -> pg_xjournal?  (Joel Jacobson <joel@trustly.com>)
Responses Re: pg_xlog -> pg_xjournal?  (Joel Jacobson <joel@trustly.com>)
Re: pg_xlog -> pg_xjournal?  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On 05/31/2015 10:46 AM, Tom Lane wrote:
> Joel Jacobson <joel@trustly.com> writes:
>> If we could turn back time, would we have picked "pg_xlog" as the most
>> optimal name for this important directory, or would we have come up with a
>> more user-friendly name?
> 
> Yeah...
> 
>> My suggestion is to use "pg_xjournal" instead of "pg_xlog" when new users
>> create a new data directory using initdb, and allow for both directories to
>> exist (exclusive or, i.e. either one or the other, but not both). That way
>> we don't complicate the life for any existing users, all their tools will
>> continue to work who rely on pg_xlog to be named pg_xlog, but only force
>> new users to do a bit of googling when they can't use whatever tool that
>> can't find pg_xlog. When they find out it's an important directory, they
>> can simply create a symlink and their old not yet updated tool will work
>> again.
> 
> Hm.  I think the impact on third-party backup tools would be rather bad,
> but there's a simple modification of the idea that might fix that:
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
> Anybody who blindly removes pg_xlog won't have done anything
> irreversible.  We could deprecate pg_xlog and stop creating the symlink
> after a few releases, once third-party tools have had a reasonable
> amount of time to adjust.
> 
> Note that we'd really also have to rename pg_clog etc if you want to
> protect against people who "rm -rf *log" without reading documentation.
> But I don't see why the same trick wouldn't work for all of them.

Allow me to be the one to point out other practical difficulties.

If we symlink pg_xlog, then it will still trip up anyone who does "rm
-rf *log*/*" or deletes files directly from inside the directory, both
of which I've seen.  Deleting the directory itself is comparatively rare
in my experience.  So for this do to any good, we'd have to plan to
(eventally, at least) get rid of the symlinks.  Do links work the same
on Windows, btw?

Plus, updating oodles and oodles of documentation.  This would have to
be done as part of the 10.0 release, I think, and we'd have to warn the
heck out of it.

Also ... if we were to rename it, it should be "pg_wal" or "pg_xact".
Please let's not add yet another term for the WAL.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD)
Next
From: Peter Eisentraut
Date:
Subject: Re: RFC: Remove contrib entirely