Re: pg_xlog -> pg_xjournal?
От | Joel Jacobson |
---|---|
Тема | Re: pg_xlog -> pg_xjournal? |
Дата | |
Msg-id | CAASwCXcWXQboLO=Nzs7DD0Tg45=xd9bEFSSsKDVR20U4XgNHfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_xlog -> pg_xjournal? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_xlog -> pg_xjournal?
|
Список | pgsql-hackers |
On Sun, May 31, 2015 at 7:46 PM, Tom Lane <tgl@sss.pgh.pa.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.
В списке pgsql-hackers по дате отправления: