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
|
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: