Re: post-freeze damage control
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-08T23:33:29Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
revert: Transform OR clauses to ANY expression
- ff9f72c68f67 17.0 landed
-
Fix incorrect calculation in BlockRefTableEntryGetBlocks.
- 55a5ee30cd65 17.0 cited
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