From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Stefan Fercot <stefan(dot)fercot(at)protonmail(dot)com>, 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-11 10:26:38 |
Message-ID: | 71fcff9e-371b-4f6a-bd34-bfe5cffb864f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/11/24 03:52, David Steele wrote:
> On 4/11/24 10:23, Tom Kincaid wrote:
>>
>> The extensive Beta process we have can be used to build confidence we
>> need in a feature that has extensive review and currently has no known
>> issues or outstanding objections.
>
> I did have objections, here [1] and here [2]. I think the complexity,
> space requirements, and likely performance issues involved in restores
> are going to be a real problem for users. Some of these can be addressed
> in future releases, but I can't escape the feeling that what we are
> releasing here is half-baked.
>
I haven't been part of those discussions, and that part of the thread is
a couple months old already, so I'll share my view here instead.
I do not think it's half-baked. I certainly agree there are limitations,
and there's all kinds of bells and whistles we could add, but I think
the fundamental infrastructure is corrent and a meaningful step forward.
Would I wish it to handle .tar for example? Sure I would. But I think
it's something we can add in the future - if we require all of this to
happen in a single release, it'll never happen.
FWIW that discussion also mentions stuff that I think the feature should
not do. In particular, I don't think the ambition was (or should be) to
make pg_basebackup into a stand-alone tool. I always saw pg_basebackup
more as an interface to "backup steps" correctly rather than a complete
backup solution that'd manage backup registry, retention, etc.
> Also, there are outstanding issues here [3] and now here [4].
>
I agree with some of this, I'll respond in the threads.
regards
Tomas
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-04-11 10:30:58 | Re: psql: Greatly speed up "\d tablename" when not using regexes |
Previous Message | Daniel Gustafsson | 2024-04-11 10:15:26 | Re: type in basebackup_incremental.c ? |