Re: post-freeze damage control - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: post-freeze damage control
Date
Msg-id ZhR-yaMiYOeofy7o@paquier.xyz
Whole thread Raw
In response to Re: post-freeze damage control  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: post-freeze damage control
Re: post-freeze damage control
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL 17 Release Management Team & Feature Freeze
Next
From: David Rowley
Date:
Subject: Re: enhance the efficiency of migrating particularly large tables