Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?
Дата
Msg-id CAB7nPqSSd79d_QVchVsVt0yLLh2pV=g+RoQVk362X6fnF0p96g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I don't think this really buys us anything.  If we'd applied it to v10
> maybe, but what do we get out of whacking it around now?
>
> "Consistency", I hear you cry!  Fair point.  But we never had a goal
> of eliminating all internal references to "xlog", just the user-facing
> ones.  And since RECOVERYXLOG is not documented, I think there's a
> good argument that it's not user-facing.  You could argue that since
> it shows up in the file system it's implicitly user-facing, and maybe
> you're right; if some other committer really wants to make this
> change, I won't grouse much.  But personally I'd favor leaving it
> alone to avoid having the behavior change a little bit in every new
> release.

I may be wrong, but I would suspect that some backup tools doing
FS-level backup are checking on the existence of this file and skip
it. From the point of view of operations, it does not matter much as
any existing RECOVERYXLOG is unlinked before being replaced by a new
one, but that would not be nice to add silently 16MB in each backup.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Upcoming commit fest will begin soon
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] More replication race conditions