Re: post-freeze damage control
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-09T11:24:06Z
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 4/9/24 01:33, Michael Paquier wrote: > 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. > I think it's a bit more nuanced, because it's about backups/restore. The bug might be subtle, and you won't learn about it until the moment when you need to restore (or perhaps even long after that). At which point "You might have taken the backup in some other way." is not really a viable exit route. Anyway, I'm still not worried about this particular feature, and I'll keep doing the stress testing. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company