Re: documenting the backup manifest file format - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: documenting the backup manifest file format
Date
Msg-id e1f94af9-4c78-539d-f381-2817d6ed5147@2ndQuadrant.com
Whole thread Raw
In response to Re: documenting the backup manifest file format  (David Steele <david@pgmasters.net>)
Responses Re: documenting the backup manifest file format  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On 4/14/20 1:33 PM, David Steele wrote:
> On 4/14/20 1:27 PM, Alvaro Herrera wrote:
>> On 2020-Apr-14, David Steele wrote:
>>
>>> On 4/14/20 12:56 PM, Robert Haas wrote:
>>>
>>>> Hmm, did David suggest that before? I don't recall for sure. I think
>>>> he had some suggestion, but I'm not sure if it was the same one.
>>>
>>> "I'm also partial to using epoch time in the manifest because it is
>>> generally easier for programs to work with.  But, human-readable
>>> doesn't
>>> suck, either."
>>
>> Ugh.  If you go down that road, why write human-readable contents at
>> all?  You may as well just use a binary format.  But that's a very
>> slippery slope and you won't like to be in the bottom -- I don't see
>> what that gains you.  It's not like it's a lot of work to parse a
>> timestamp in a non-internationalized well-defined human-readable format.
>
> Well, times are a special case because they are so easy to mess up.
> Try converting ISO-8601 to epoch time using the standard C functions
> on a system where TZ != UTC. Fun times.
>
>


Even if it's a zulu time? That would be pretty damn sad.


cheers


andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Hamid Akhtar
Date:
Subject: Re: Do we need to handle orphaned prepared transactions in the server?
Next
From: Teja Mupparti
Date:
Subject: Re: Corruption during WAL replay