Re: [HACKERS] Timeline ID in backup_label file - Mailing list pgsql-hackers

From David Steele
Subject Re: [HACKERS] Timeline ID in backup_label file
Date
Msg-id 1372088e-08bc-65bb-9903-a2f33169e470@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] Timeline ID in backup_label file  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Timeline ID in backup_label file  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 11/27/17 7:11 PM, Michael Paquier wrote:
> On Mon, Nov 27, 2017 at 11:06 PM, David Steele <david@pgmasters.net> wrote:
>> On 11/15/17 10:09 PM, Michael Paquier wrote:
>>>
>>> read_backup_label() is a static function in the backend code. With #2
>>> I do not imply to change the order of the elements written in the
>>> backup_label file, just to make the way they are parsed smarter.
>>
>> My point is that the order *could* be changed and it wouldn't be noticed
>> if the read function were improved as you propose.
>>
>> I'm not against the idea, just think we should continue to enforce the
>> order unless we decide an interface break is OK.
> 
> I still don't quite understand here. The order the items are read does
> not cause a backward-incompatible change. True that there is no reason
> to change that either now.

Perhaps I'm the one who is misunderstanding. If you propose a patch I'll 
be happy to review it, though I doubt there is a lot to be gained even 
if it would be a better implementation.

Regards,
-- 
-David
david@pgmasters.net


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Expression based aggregate transition / combine function invocation
Next
From: Amit Langote
Date:
Subject: Re: Isn't partition drop code seriously at risk of deadlock?