Re: post-freeze damage control

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: post-freeze damage control
Дата
Msg-id ZhR-yaMiYOeofy7o@paquier.xyz
обсуждение исходный текст
Ответ на Re: post-freeze damage control  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: post-freeze damage control  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: post-freeze damage control  (John Naylor <johncnaylorls@gmail.com>)
Список pgsql-hackers
On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
> I don't feel too particularly worried about this. Yes, backups are super
> important because it's often the only thing you have left when things go
> wrong, and the incremental aspect is all new. The code I've seen while
> doing the CoW-related patches seemed very precise and careful, and the
> one bug we found & fixed does not make it bad.
>
> Sure, I can't rule there being more bugs, but I've been doing some
> pretty extensive stress testing of this (doing incremental backups +
> combinebackup, and comparing the results against the source, and that
> sort of stuff). And so far only that single bug this way. I'm still
> doing this randomized stress testing, with more and more complex
> workloads etc. and I'll let keep doing that for a while.
>
> Maybe I'm a bit too happy-go-lucky, but IMO the risk here is limited.

Even if there's a critical bug, there are still other ways to take
backups, so there is an exit route even if a problem is found and even
if this problem requires a complex solution to be able to work
correctly.

This worries me less than other patches like the ones around heap
changes or the radix tree stuff for TID collection plugged into
vacuum, which don't have explicit on/off switches AFAIK.
--
Michael

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 17 Release Management Team & Feature Freeze
Следующее
От: David Rowley
Дата:
Сообщение: Re: enhance the efficiency of migrating particularly large tables