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

From Christoph Berg
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id 20161019110528.d5w7t6qnmpsosmjg@msg.df7cb.de
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Renaming of pg_xlog and pg_clog  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Re: Bruce Momjian 2016-10-19 <20161018220909.GA11661@momjian.us>
> > There's actually another instance of "rename so people shoot their
> > feet less often" here: pg_resetxlog, which is a user-facing tool.
> > Folks on #postgresql have repeatedly been joking that it should rather
> > be named pg_eatmydata, given the number of "howtos" on the web that
> > make use of it. Maybe this is the chance to find a less
> > innocent-sounding name. (Or add a mandatory --rewind-my-data switch.)
> 
> I wonder how many of the uses of pg_resetxlog were caused by mistakenly
> removing the pg_xlog directory.   My point is renaming pg_xlog might
> reduce mistake use of pg_resetxlog.

I don't think there's much of a connection. There are people who
clean up disk space by removing everything that sounds like log files.
For those people renaming the directories makes sense so they don't
have that idea.

There are other people who have random database startup problems, ask
google, and end up with applying some pg_resetxlog advice (that
doesn't necessarily fit their problem). For those people renaming
pg_resetxlog to something that sounds more like "it will break your
data, use as last resort only" might make sense. (Though I don't have
a good suggestion, and the cost of renaming utilities is higher than
renaming some internal directory names.)

The question would now be if there's people who used pg_resetxlog
because they thought it freed up disk space, and if renaming either
would have prevented that. I'm less sure about that.

(tl;dr: rename pg_xlog yes, rename pg_resetxlog only if we have a good
alternative.)

Christoph



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: LLVM Address Sanitizer (ASAN) and valgrind support
Next
From: Heikki Linnakangas
Date:
Subject: Re: FSM corruption leading to errors