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

From Tom Lane
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id 9852.1476464181@sss.pgh.pa.us
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Renaming of pg_xlog and pg_clog  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 10/14/16 9:06 AM, Stephen Frost wrote:
>> It'd probably be easier to move the things that are *not* PG internal
>> (eg: config files, et al) *out* of the data directory and into somewhere
>> sensible, like /etc ...

> I do think it would be an improvement to segregate things users are 
> expected to touch (*.conf and pg_log are what come to mind) from 
> everything else, which could easily be done by moving everything else to 
> an internal/ directory. I agree that's not much of an improvement for 
> pg_[cx]log, but we could create internal/ as well as rename some things.

I can't get excited about that at all.  It will just get in the way of
the actually useful end goal we had for directory restructuring, which
was to separate data to be copied by pg_basebackup from data not to be
copied by it.  And in reality, people who don't understand that the
contents of PGDATA should be treated as "hands off unless documented
otherwise" are not going to be any less likely to shoot themselves in
the foot just because there's a directory named "internal" or
"here_be_dragons" or "keep_out_this_means_you" in the way.

I'd also suggest that an extra level of directory search to get at
database data files is not free.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: process type escape for log_line_prefix
Next
From: Mario De Frutos Dieguez
Date:
Subject: Re: signal handling in plpython