Re: Reliable WAL file shipping over unreliable network

From: Rui DeSousa <rui(dot)desousa(at)icloud(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: Dianne Skoll <dfs(at)roaringpenguin(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Reliable WAL file shipping over unreliable network
Date: 2018-03-01 02:27:24
Message-ID: 9DDA6F85-077E-4F8D-8708-632CC2907D3C@icloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

STS is initialized as 3; and is only set to zero if rsync returns zero.

> On Feb 28, 2018, at 8:59 PM, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
>
> Hi
>
> On 01/03/18 14:10, Rui DeSousa wrote:
>> I’ve tested this and it seems that there is a still a bug in rsync (rsync version 3.1.2 protocol version 31). I used a 1GB archive filesytem to allow for an out of space test case. Not sure of the actual cause as it seems to work a few times; however, it then fails leaving a truncated file and returning a success code.
>>
>>
>> Archive Script critical code:
>>
>> OUTPUT=$(rsync -ac $XLOGFILE $ARCH_SERVER:$ARCH_DIR/$WALFILE)
>> if [ $? == 0 ]; then
>> STS=0
>> echo "Success: $WALFILE" >> /tmp/waltest.log
>> else
>> echo "Failed: $WALFILE" >> /tmp/waltest.log
>> fi
>>
>> exit $STS
>>
>>
>>
>
> Looking at the above snippet, $STS is not properly initialized in the failure section of the code...so you might be getting false 0 returns when rsync is actually setting some other value.
>
> regards
>
> Mark

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ted EH 2018-03-01 02:43:48 WAL segment not replicated
Previous Message Mark Kirkwood 2018-03-01 01:59:14 Re: Reliable WAL file shipping over unreliable network