| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
|---|---|
| To: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com>, Dianne Skoll <dfs(at)roaringpenguin(dot)com> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Reliable WAL file shipping over unreliable network |
| Date: | 2018-03-01 01:59:14 |
| Message-ID: | 5a49c387-e4f4-f70c-537c-9c338c80b687@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rui DeSousa | 2018-03-01 02:27:24 | Re: Reliable WAL file shipping over unreliable network |
| Previous Message | Dianne Skoll | 2018-03-01 01:54:58 | Re: Reliable WAL file shipping over unreliable network |