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

From David Steele
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id 6e830544-d3d0-3577-6132-93769f06f8a9@pgmasters.net
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Renaming of pg_xlog and pg_clog  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 8/27/16 4:33 AM, Michael Paquier wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund <andres@anarazel.de> wrote:
>> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>>> I agree with all that.  But the subject line is specifically about
>>> moving pg_xlog.  So if your opinion is that we shouldn't move pg_xlog,
>>> then that is noted.  But if we were to move it, we can think about a
>>> good place to move it to.
>>
>> I think it's probably worth moving pg_xlog, because the benefit also
>> includes preventing a few users from shooting themselves somewhere
>> vital. That's imo much less the case for some of the other moves.  But I
>> still don't think think a largescale reorganization is a good idea,
>> it'll just stall and nothing will happen.
> 
> OK, so let's focus only on the renaming mentioned in $subject. So far
> as I can see on this thread, here are the opinions of people who
> clearly gave one:
> - Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
> David's input),  Magnus
> - Rename them, hard break not OK: Fujii-san (perhaps do nothing?)
> - Do nothing: Simon (add a README), Tom, Peter E
> 
> As far as I can see, there is a consensus to not rename pg_xlog to
> pg_journal and avoid using a third meaning, but instead use pg_wal. I
> guess that now the other renaming would be pg_clog -> pg_xact. Other
> opinions? Forgot you here?

I'm definitely +1 for a hard break (internal links are a pain).  Ideally
I'd would like to see:

pg_xlog -> pg_wal
pg_clog -> pg_xact
pg_logical -> pg_replgcl

pg_logical is a special case because it contains both ephemeral and
persistent files.  I'd like to see the temporary files in
pg_tmp/pg_replgcl (or whatever it gets renamed to) but that means that
pg_tmp must be on the same device to get atomic renames.  It would be
enough if pg_replgcl had a pgsql_tmp subdirectory so temp files are
excluded from backups with the current logic.

I'm also in favor of leaving configuration files where they are because
these are the files that are most likely to be checked/manipulated in
various user scripts (other than pg_xlog) of course.

As Stephen mentioned I would like to see purely ephemeral data moved
into its own directory.  Maybe $PGDATA/pg_tmp?

pg_subtrans -> pg_tmp/pg_subxact
pg_stat_tamp -> pg_tmp/pg_stat
pg_dynshmem -> pg_tmp/pg_dynshmem (or pg_shmem?)
pg_notify -> pg_tmp/pg_notify
pg_replslot -> pg_tmp/pg_repslot
pg_serial -> pg_tmp/pg_serial
pg_snapshots -> pg_tmp/pg_snapshot

It would be helpful if we had consistent temp directory naming
everywhere so it's clear what to exclude when it is not practical to put
files in the root pg_tmp.  As such I would rename pgsql_tmp to pg_tmp in
base and pg_tblspc/*/*/.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: maksim
Date:
Subject: [WIP] Patches to enable extraction state of query execution from external session