Re: post-freeze damage control

From: David Steele <david(at)pgmasters(dot)net>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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 21:48:12
Message-ID: bf6372c1-b9af-4dea-a054-895e2870b6cc@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/11/24 20:26, Tomas Vondra wrote:
>
> 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.

Fair enough, but the current release is extremely limited and it would
be best if that was well understood by users.

> 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.

Right -- this is exactly my issue. pg_basebackup was never easy to use
as a backup solution and this feature makes it significantly more
complicated. Complicated enough that it would be extremely difficult for
most users to utilize in a meaningful way.

But they'll try because it is a new pg_basebackup feature and they'll
assume it is there to be used. Maybe it would be a good idea to make it
clear in the documentation that significant tooling will be required to
make it work.

Regards,
-David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-04-11 22:04:03 Re: Table AM Interface Enhancements
Previous Message Andres Freund 2024-04-11 21:30:23 Re: Issue with the PRNG used by Postgres