Re: Error while copying a large file in pg_rewind

On Thu, Jul 6, 2017 at 8:51 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Thu, Jul 6, 2017 at 4:18 PM, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> wrote:
>> But, I'm little concerned/doubt regarding the following part of the code.
>> +/*
>> + * Converts an int64 from network byte order to native format.
>> + */
>> +static int64
>> +pg_recvint64(int64 value)
>> +{
>> + union
>> + {
>> + int64 i64;
>> + uint32 i32[2];
>> + } swap;
>> + int64 result;
>> +
>> + swap.i64 = value;
>> +
>> + result = (uint32) ntohl(swap.i32[0]);
>> + result <<= 32;
>> + result |= (uint32) ntohl(swap.i32[1]);
>> +
>> + return result;
>> +}
>> Does this always work correctly irrespective of the endianess of the
>> underlying system?
>
> I think this will have problem, we may need to do like
>
> and reverse complete array if byte order is changed

This comes from the the implementation of 64b-large objects, which was
first broken on big-endian systems, until Tom fixed it with the
following commit, and this looks fine to me:
commit: 26fe56481c0f7baa705f0b3265b5a0676f894a94
author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
date: Mon, 8 Oct 2012 18:24:32 -0400
Code review for 64-bit-large-object patch.

At some point it would really make sense to group all things under the
same banner (64-b LO, pg_basebackup, and now pg_rewind).

> or we can use something like "be64toh"

That's even less portable. For example macos would need a macro to map
to OSSwapBigToHostInt64 or OSSwapLittleToHostInt64 from OSByteOrder.h.
Brr.
--
Michael