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

From Mark Kirkwood
Subject Re: pg_xlog -> pg_xjournal?
Date
Msg-id 556D7B35.1060200@catalyst.net.nz
Whole thread Raw
In response to pg_xlog -> pg_xjournal?  (Joel Jacobson <joel@trustly.com>)
Responses Re: pg_xlog -> pg_xjournal?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 01/06/15 05:29, Joel Jacobson wrote:
> While anyone who is familiar with postgres would never do something as
> stupid as to delete pg_xlog,
> according to Google, there appears to be a fair amount of end-users out
> there having made the irrevocable mistake of deleting the precious
> directory,
> a decision made on the assumption that since "it has *log* in the name
> so it must be unimportant"
> (http://stackoverflow.com/questions/12897429/what-does-pg-resetxlog-do-and-how-does-it-work).
>
> 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?
>
> Personally, I have never had any problems with pg_xlog, but I realize
> there are quite a few unlucky new users who end up in trouble.
>
> 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.
>
> Thoughts?
>

+1

Strongly agree - I have had people on my dba course ask about deleting 
these pesky 'log' directories (obvious confusion/conflation with pg_log 
...)! A change of name would help reduce the temptation!

regards

Mark



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Fabien COELHO
Date:
Subject: Re: checkpointer continuous flushing