From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_xlog -> pg_xjournal? |
Date: | 2015-05-31 20:44:54 |
Message-ID: | CAASwCXcWXQboLO=Nzs7DD0Tg45=xd9bEFSSsKDVR20U4XgNHfg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 31, 2015 at 7:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm. I think the impact on third-party backup tools would be rather bad,
> but there's a simple modification of the idea that might fix that:
> just always create pg_xlog as a symlink to pg_xjournal during initdb.
> Anybody who blindly removes pg_xlog won't have done anything
> irreversible. We could deprecate pg_xlog and stop creating the symlink
> after a few releases, once third-party tools have had a reasonable
> amount of time to adjust.
I like the solution. Simple and effective.
+1
> In the end though, this is a lot of thrashing for a problem that
> only comes up rarely ...
It happens often enough for the problem to be the first mentioned
use-case of pg_resetxlog at Stack Overflow:
"pg_resetxlog is a tool of last resort for getting your database
running again after:
1. You deleted files you shouldn't have from pg_xlog;"
(http://stackoverflow.com/questions/12897429/what-does-pg-resetxlog-do-and-how-does-it-work)
Preventing failure in the case of faults is of course one of the
primary objectives of any database.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-05-31 22:08:03 | Re: nested loop semijoin estimates |
Previous Message | Andres Freund | 2015-05-31 20:16:29 | Re: [CORE] postpone next week's release |