Re: post-freeze damage control - Mailing list pgsql-hackers

From David Steele
Subject Re: post-freeze damage control
Date
Msg-id 5806233a-55f1-4e22-ae22-2bda7e1f48ed@pgmasters.net
Whole thread Raw
In response to Re: post-freeze damage control  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: post-freeze damage control
List 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 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.

I'm not sure that I really buy this argument, anyway. It is not uncommon 
for significant features to spend years in development before they are 
committed. This feature went from first introduction to commit in just 
over six months. Obviously Robert had been working on it for a while, 
but for a feature this large six months is a sprint.

Regards,
-David



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Can't find not null constraint, but \d+ shows that
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition