Re: [HACKERS] Timeline ID in backup_label file

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [HACKERS] Timeline ID in backup_label file
Date: 2017-11-28 00:40:44
Message-ID: 1372088e-08bc-65bb-9903-a2f33169e470@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/27/17 7:11 PM, Michael Paquier wrote:
> On Mon, Nov 27, 2017 at 11:06 PM, David Steele <david(at)pgmasters(dot)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(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-11-28 00:43:25 Re: Isn't partition drop code seriously at risk of deadlock?
Previous Message Andres Freund 2017-11-28 00:31:21 Expression based aggregate transition / combine function invocation