Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
Дата
Msg-id CAH2-Wz=8pqiy5FFO+1CMzB-fouO+uX0bS3DP41mWXkraea-auw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers
On Mon, May 1, 2023 at 9:16 AM Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, May 1, 2023 at 9:08 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > I disagree. If you start the cluster in single-user mode, you can
> > actually wrap it around, unless something has changed that I don't
> > know about.
>
> This patch relies on John's other patch which strongly discourages the
> use of single-user mode. Were it not for that, I might agree.

Also, it's not clear that the term "wraparound" even describes what
happens when you corrupt the database by violating the "no more than
~2.1 billion XIDs distance between any two unfrozen XIDs" invariant in
single-user mode. What specific thing will have wrapped around? It's
possible (and very likely) that every unfrozen XID in the database is
from the same 64-XID-wise epoch.

I don't think that we need to say very much about this scenario (and
nothing at all about the specifics in "Routine Vacuuming"), so maybe
it doesn't matter much. But I maintain that it makes most sense to
describe this scenario as a violation of the "no more than ~2.1
billion XIDs distance between any two unfrozen XIDs" invariant, while
leaving the term "wraparound" out of it completely. That terms has way
too much baggage.

--
Peter Geoghegan



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

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: base backup vs. concurrent truncation
Следующее
От: Eric Ridge
Дата:
Сообщение: Re: [PATCH] Support % wildcard in extension upgrade filenames