From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: post-freeze damage control |
Date: | 2024-04-08 23:16:02 |
Message-ID: | 657881e9-18d1-439e-82a2-4dc691b1e4fa@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/8/24 21:47, Robert Haas wrote:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
>
> ...
>
> - Incremental backup could have all sorts of terrible data-corrupting
> bugs. 55a5ee30cd65886ff0a2e7ffef4ec2816fbec273 was a full brown-paper
> bag level fix, so the chances of there being further problems are
> probably high.
>
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.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-08 23:26:39 | Re: PostgreSQL 17 Release Management Team & Feature Freeze |
Previous Message | Tom Lane | 2024-04-08 23:02:58 | Re: enhance the efficiency of migrating particularly large tables |