Horton

Re: Renaming of pg_xlog and pg_clog

Joshua D. Drake <jd@commandprompt.com>

View thread View on postgr.es
From: "Joshua D. Drake" <jd@commandprompt.com>
To: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Christoph Berg <myon@debian.org>, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Craig Ringer <craig.ringer@2ndquadrant.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2016-10-20T16:19:42Z
Lists: pgsql-hackers 
On 10/20/2016 09:12 AM, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:

> That said, I'd also like to see a --force or similar option or mechanism
> put in place to reduce the risk of users trashing their system because
> they think pg_resetwal is "safe." ("It's just gonna reset things to make
> the database start again, should be fine.").
>
> pg_destroydb almost seems like a better choice, though I suppose
> 'pg_clearwal' would be more acceptable.  Doesn't have quite the same
> impact though.

pg_dropwal

Users won't *drop* things they shouldn't on purpose (usually) but they 
will reset and will clear them. Destroydb isn't anymore accurate because 
it doesn't destroy it. Instead it makes it so I can log in again and see 
my data.

(Yes we all know the real implications with it but from a DUH user 
perspective...)

Sincerely,

JD


-- 
Command Prompt, Inc.                  http://the.postgres.company/
                         +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

Commits

  1. Rename "pg_clog" directory to "pg_xact".

  2. Improve error reporting in pg_upgrade's file copying/linking/rewriting.