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 7405.1472316608@sss.pgh.pa.us
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  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> 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

Hm, if you read me as voting against renaming pg_xlog, that wasn't
the conclusion I meant to convey.  I'm against moving/renaming the
configuration files, because I think that will break a lot of users'
scripts and habits without really buying much.  But I'm for consolidating
all the files that should not be copied by backup tools into one
subdirectory, and I think that while we're doing that it would be sensible
to rename pg_xlog and pg_clog to something that doesn't sound like it's
scratch data.  I'm on the fence about whether pg_logical ought to get
renamed.

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

Yeah, +1 for pg_wal, we do not need yet another name for that.

> I guess that now the other renaming would be pg_clog -> pg_xact.

We already have pg_subtrans, so it seems like pg_trans is an obvious
suggestion.  I'm not sure whether the other precedent of pg_multixact
is a stronger one than that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: OpenSSL 1.1 breaks configure and more
Next
From: Alvaro Herrera
Date:
Subject: Re: Renaming of pg_xlog and pg_clog