Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBmL6-0000Xm-VJ for pgsql-admin@arkaria.postgresql.org; Wed, 03 Apr 2019 20:18:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hBmL5-0002Qt-D0 for pgsql-admin@arkaria.postgresql.org; Wed, 03 Apr 2019 20:18:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBmL4-0002Qm-Fs for pgsql-admin@lists.postgresql.org; Wed, 03 Apr 2019 20:18:27 +0000 Received: from sonic315-37.consmr.mail.gq1.yahoo.com ([98.137.65.61]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBmKy-0002Kr-6J for pgsql-admin@lists.postgresql.org; Wed, 03 Apr 2019 20:18:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1554322693; bh=aElXbXjrL6aWCyEeBQc18ch3BnYdSW8OVBPMfsuuQG0=; h=Date:From:To:Subject:References:From:Subject; b=ukvv1fK8LG/9OZ8efIzUbMJEpcDBPgDjWoBsDluTXcW0WX5bAoPKcfrE3DoQLMb/FG1/oSTKUUyKd9P2+lRzCteov0vehhNND+x+N3K02Zhf4wMZmt8iOvdTXu+Fqqa7Ujt8hT/8h0dUGhrKquQ2a/oJemdKSz9/JX/cOxzH8hU+frZSsp32Ox7Uu87+vQ3FrGNNBBbaqnxNoPtGYp/+tcNwFvN506wPU81Y1c9vj3y0hXYCsKGewwzrHNQjiE9YzkU4R5nhm9VRAIQcn9gVM7p/sGp6Kc+0OJSpcKOP2fZHF4gz2hFdooAA2g2KVPjknJy/YwjT+IPv9w7ALXZz5Q== X-YMail-OSG: XsjcopYVM1kLypr18r4abpds3lFjXTyLKGfxSLRNzCtqa9L5yWc_9yLvYmR0icN g2hXUaoSz_98yMlvG59JtFW8eOWfok27obttioLVb6Ok40ySz1uET2w8VF9FPkGNG.85OeSWTD0E 8VIrkVJJCpxSG91L1bgirsN32A3w1QkmwQb9OSEB9Y00O7eGTRUxY_3ycXkpsJtTsANyK4ntm9DO r5wHoZ1STajO6SQhvXdQuVXIQivgUuJ4kTSDjcTRqMFGp2IhvimLuyrtRGdXj3cCkXKeCnl9NuWK YyePJ6p8hj0f8ic8CKZA9VzNhMFDC7QIsm1XnPUCSrUYDBDTcNl6P9lIWwcd16cLLAFMufUV6Lki Wtz7d0KoG9MCg1OvQCk.oX4Md0.NGzSMxqg1k8K1dSxfGwd2pCOb8MjoS.zaSI48oNJsmjmSlkd6 gZhBowsV1X3Uc85VZ5kGHkoBgpdOJL5EIEhJSM3toG_KEw7VI6kCX4zqrPKrbtZgKGRlL0W.1vN1 Os_zuANbJ9g4OUE64_lSlkPzM.ekZkcyz7jqqphPQtFmBkws_8Y_0gzybd3anllfEUu8VhBhApmC YMk6prH9SZQnxm3XPfcpUJz2xTDVSRmhBWM9eFOYrt7UrpVpNpAdms9yj7l.7kcwDInOHg.MPpQy .q7ImOIsgL8WEtliOumGmDgyF5J5BbiL3FCT4z52oDzDsz7xlMDP741vWePhua61eebtwxWvXmre HJaiSrAdtkRKSM35ccQ8WwBnxVcb_gli1DWf84u7YYGTaDIr_4Vu9p9soaDYNyGua3pZ86wyhiFH VHwN5o3eu5ihFZ5RMm6fBgjr2y_qgcFzhNDpl4p6vy8ZzOENT4SJGrG14fRwk33GkLIO9Oj59j9L DdNax2AAHJYMmCchJN6YZxRiPFCo_AhDN6.5r_y7VxtkrZMGiYqe2EpyQSIVpozSR5Vn8pDJS0gz XhatZrWUVYrfMER6Q4AzPrd0CNVyrm45d4Nm0i0tNYMYVYIljDefnN1cpUfUlmBU2eFdbRU338J5 eo7wrNvg_OskNm7QRdyFdyH37Ka9s2Lq.BgX4V9zhudG9u3tDNZ3qfqTBl9H25e0uDHVI35pr_XE LiMnSwnfii8uhTDK5ok0IhNziK269P7bKSBr64kTpxUL9jUyC Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 3 Apr 2019 20:18:13 +0000 Date: Wed, 3 Apr 2019 20:16:12 +0000 (UTC) From: LEROY TENNISON To: Pgsql-admin Message-ID: <1222332414.512321.1554322572303@mail.yahoo.com> Subject: archive_command options? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_512320_1996339066.1554322572302" References: <1222332414.512321.1554322572303.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13385 YMailNorrin Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Content-Length: 2197 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_512320_1996339066.1554322572302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Postgresql documentation lists the following as an archive command for log = shipping: archive_command =3D 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/serv= er/archivedir/%f' The problem is that it is very fragile.=C2=A0 If anything breaks the copy (= either system failing, network issues) then log shipping stops because the = file exists in some intermediate state.=C2=A0 The result is that logs build= up on the source system filling disk space.=C2=A0 I've had to deal with a = few of these this week, in two cases the file system was 98% full.=C2=A0 Is= there a reason rsync isn't used?=C2=A0 It has the ability to restart inter= rupted transfers.=C2=A0 I don't want to use it only to find out i got mysel= f into another predicament.=C2=A0 Any other less-fragile options?=C2=A0 Tha= nks for the help. ------=_Part_512320_1996339066.1554322572302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Postgresql documentation lists the following as an archive command fo= r log shipping:

archive_command =3D 'test ! -f /mn= t/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

The problem is that it is very fragile.  If anything = breaks the copy (either system failing, network issues) then log shipping s= tops because the file exists in some intermediate state.  The result i= s that logs build up on the source system filling disk space.  I've ha= d to deal with a few of these this week, in two cases the file system was 9= 8% full.  Is there a reason rsync isn't used?  It has the ability= to restart interrupted transfers.  I don't want to use it only to fin= d out i got myself into another predicament.  Any other less-fragile o= ptions?  Thanks for the help.
------=_Part_512320_1996339066.1554322572302--