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