Re: pg_xlog -> pg_xjournal?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_xlog -> pg_xjournal?
Дата
Msg-id 2899.1433094393@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_xlog -> pg_xjournal?  (Joel Jacobson <joel@trustly.com>)
Ответы Re: pg_xlog -> pg_xjournal?  (Joel Jacobson <joel@trustly.com>)
Re: pg_xlog -> pg_xjournal?  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Re: pg_xlog -> pg_xjournal?  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Joel Jacobson <joel@trustly.com> writes:
> If we could turn back time, would we have picked "pg_xlog" as the most
> optimal name for this important directory, or would we have come up with a
> more user-friendly name?

Yeah...

> My suggestion is to use "pg_xjournal" instead of "pg_xlog" when new users
> create a new data directory using initdb, and allow for both directories to
> exist (exclusive or, i.e. either one or the other, but not both). That way
> we don't complicate the life for any existing users, all their tools will
> continue to work who rely on pg_xlog to be named pg_xlog, but only force
> new users to do a bit of googling when they can't use whatever tool that
> can't find pg_xlog. When they find out it's an important directory, they
> can simply create a symlink and their old not yet updated tool will work
> again.

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.

Note that we'd really also have to rename pg_clog etc if you want to
protect against people who "rm -rf *log" without reading documentation.
But I don't see why the same trick wouldn't work for all of them.

A more difficult question is whether we'd also rename pg_resetxlog,
pg_receivexlog, etc.  It would be hard to make those changes similarly
transparent.

In the end though, this is a lot of thrashing for a problem that
only comes up rarely ...
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joel Jacobson
Дата:
Сообщение: pg_xlog -> pg_xjournal?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [CORE] postpone next week's release