Re: base backup vs. concurrent truncation

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: base backup vs. concurrent truncation
Дата
Msg-id CAM-w4HMDSTsuVbv3LTeCkgzWawiWD7Y6FVDnefhHs7wmGgO3PQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: base backup vs. concurrent truncation  (Andres Freund <andres@anarazel.de>)
Ответы Re: base backup vs. concurrent truncation  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Including the pre-truncation length in the wal record is the obviously
solid approach and I none of the below is a good substitution for it.
But....

On Tue, 25 Apr 2023 at 13:30, Andres Freund <andres@anarazel.de> wrote:
>
> It isn't - but the alternatives aren't great either. It's not that easy to hit
> this scenario, so I think something along these lines is more palatable than
> adding a pass through the entire data directory.

Doing one pass through the entire data directory on startup before
deciding the directory is consistent doesn't sound like a crazy idea.
It's pretty easy to imagine bugs in backup software that leave out
files in the middle of tables -- some of us don't even have to
imagine...

Similarly checking for a stray next segment whenever extending a file
to maximum segment size seems like a reasonable thing to check for
too.

These kinds of checks are the kind of paranoia that catches filesystem
bugs, backup software bugs, cron jobs, etc that we don't even know to
watch for.

-- 
greg



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

Предыдущее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Unlinking Parallel Hash Join inner batch files sooner
Следующее
От: David Rowley
Дата:
Сообщение: Re: benchmark results comparing versions 15.2 and 16