Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1er79f-0003jK-Mf for pgsql-admin@arkaria.postgresql.org; Wed, 28 Feb 2018 19:12:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1er79e-0000sD-P5 for pgsql-admin@arkaria.postgresql.org; Wed, 28 Feb 2018 19:12:42 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1er79e-0000s4-EX for pgsql-admin@lists.postgresql.org; Wed, 28 Feb 2018 19:12:42 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1er79b-00008l-It for pgsql-admin@lists.postgresql.org; Wed, 28 Feb 2018 19:12:41 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 3149CC0835; Wed, 28 Feb 2018 19:12:38 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l698kvPPXvEd; Wed, 28 Feb 2018 19:12:38 +0000 (UTC) Received: from shr-mbp-2.allegisgroup.com (unknown [216.152.106.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id A9AB8C07A8; Wed, 28 Feb 2018 19:12:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Reliable WAL file shipping over unreliable network From: scott ribe In-Reply-To: Date: Wed, 28 Feb 2018 12:11:15 -0700 Cc: Rui DeSousa , pgsql-admin@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <400AC9CD-1E43-422C-A689-70BDBAFF231E@elevated-dev.com> <954e01b6-b240-eb9a-5feb-8efd202fef5a@shopzeus.com> <9BE48599-5417-42BF-A7D3-554590878841@elevated-dev.com> <45F65094-CF9C-4BC4-AF56-2FE299F79EFF@icloud.com> To: =?utf-8?Q?Nagy_L=C3=A1szl=C3=B3_Zsolt?= X-Mailer: Apple Mail (2.3445.5.20) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Feb 28, 2018, at 12:03 PM, Nagy L=C3=A1szl=C3=B3 Zsolt = wrote: >=20 > There is a --temp-dir option that suggests that data is written to = temporary files first. But that is only a suggestion. I don't see = anything explicit about writting data to temporary files and renaming = them once they are complete. Seems hard to me to make it more clear: -T, --temp-dir=3DDIR This option instructs rsync to use DIR as a scratch = directory when creating temporary copies of the files transferred = on the receiving side. The default behavior is to create each = tempo- rary file in the same directory as the associated = destination file. And: --delay-updates This option puts the temporary file from each updated file = into a holding directory until the end of the transfer, at = which time all the files are renamed into place in rapid succession. = This attempts to make the updating of the files a little more = atomic. By default the files are placed into a directory named = ".~tmp~" in each file's destination directory, but if you've = specified the --partial-dir option, that directory will be used = instead. See the comments in the --partial-dir section for a = discussion of how this ".~tmp~" dir will be excluded from the = transfer, and what you can do if you wnat rsync to cleanup old = ".~tmp~" dirs that might be lying around. Conflicts with = --inplace and --append. -- Scott Ribe https://www.linkedin.com/in/scottribe/ (303) 722-0567