Re: BUG #7534: walreceiver takes long time to detect n/w breakdown

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #7534: walreceiver takes long time to detect n/w breakdown
Date: 2012-10-16 12:31:08
Message-ID: 507D538C.80805@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 15.10.2012 19:31, Fujii Masao wrote:
> On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> On 15.10.2012 13:13, Heikki Linnakangas wrote:
>>>
>>> Oh, I didn't remember that we've documented the specific structs that we
>>> pass around. It's quite bogus anyway to explain the messages the way we
>>> do currently, as they are actually dependent on the underlying
>>> architecture's endianess and padding. I think we should refactor the
>>> protocol to not transmit raw structs, but use pq_sentint and friends to
>>> construct the messages. This was discussed earlier (see
>>>
>>> http://archives.postgresql.org/message-id/4FE2279C.2070506@enterprisedb.com)
>>> I think there's consensus that 9.3 would be a good time to do that as we
>>> changed the XLogRecPtr format anyway.
>>
>>
>> This is what I came up with. The replication protocol is now
>> architecture-independent. The WAL format itself is still
>> architecture-independent, of course, but this is useful if you want to e.g
>> use pg_receivexlog to back up a server that runs on a different platform.
>>
>> I chose the int64 format to transmit timestamps, even when compiled with
>> --disable-integer-datetimes.
>>
>> Please review if you have the time..
>
> Thanks for the patch!
>
> When I ran pg_receivexlog, I encountered the following error.

Yeah, clearly I didn't test this near enough...

I fixed the bugs you bumped into, new version attached.

> + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(int64);
> + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(char);
>
> These should be macro, to avoid calculation overhead?

The compiler will calculate this at compilation time, it's going to be a
constant at runtime.

- Heikki

Attachment Content-Type Size
make-replication-protocol-arch-independent-2.patch text/x-diff 36.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Vaclav Juza 2012-10-16 13:49:32 Re: BUG #7598: Loss of view performance after dump/restore of the view definition
Previous Message Craig Ringer 2012-10-16 12:24:20 Re: [Spam] Re: BUG #7577: JDBC Driver - Compiled with Java 7

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-10-16 12:36:22 Re: Global Sequences
Previous Message Markus Wanner 2012-10-16 12:26:29 Re: Global Sequences