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 1er716-00038H-Nv for pgsql-admin@arkaria.postgresql.org; Wed, 28 Feb 2018 19:03:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1er715-0005yI-7K for pgsql-admin@arkaria.postgresql.org; Wed, 28 Feb 2018 19:03:51 +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 1er714-0005y1-9e for pgsql-admin@lists.postgresql.org; Wed, 28 Feb 2018 19:03:51 +0000 Received: from shopzeus.com ([87.229.70.149]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1er711-0008Nd-5Z for pgsql-admin@lists.postgresql.org; Wed, 28 Feb 2018 19:03:48 +0000 Received: from [127.127.127.127] (localhost [127.127.127.127]) (Authenticated sender: gandalf) by shopzeus.com (Postfix) with ESMTPSA id 351C0889B83C; Wed, 28 Feb 2018 13:01:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shopzeus.com; s=shopzeus_com; t=1519840874; bh=YYvOX+c9bYC15QeT1ia0ULuSdsFqL6crr3IArdDf1sg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MXzo4N6W06kvcoUc+LDodw4qie+3+1aDUTByGFilBRzIJ3unp/3T2YRp4Yjn5/cDE SeN5RarWEoNcaHc6HqnuB6lZn0mgY5PoAFvJP7Xul0GoXNAMoGTgvEbSdCXsRf3iKL vEeZ6sCi7QHCWfT+NHZdz5BNtQeF6Vy/VK4qQ6s5hPO6Kl83dqzA31Pyx7f7kT7nlC I6uNnbSPReiyWHYR4YXYLnZB1T7LAekzxicTLUh3eDKcXDdRDQkLScaNuLqpEZe2K9 BqJdgucaQf1mFrFEBAFbsvLOhdS6HuKyxaFCW5a3MoS0U5pCLibjmpvh4pv7T0zo/U gWBB2lFlo8oKw== Subject: Re: Reliable WAL file shipping over unreliable network To: Rui DeSousa , scott ribe Cc: pgsql-admin@lists.postgresql.org 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> From: =?UTF-8?Q?Nagy_L=c3=a1szl=c3=b3_Zsolt?= Message-ID: Date: Wed, 28 Feb 2018 20:03:43 +0100 MIME-Version: 1.0 In-Reply-To: <45F65094-CF9C-4BC4-AF56-2FE299F79EFF@icloud.com> Content-Type: multipart/alternative; boundary="------------C626A346606548EF920AF610" Content-Language: hu List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------C626A346606548EF920AF610 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> >> >> There seem to be 2 fundamental misunderstandings here: >> >> 1) That other processes cannot see data written to a file until it is >> flushed to disk; this is not true; while file data is still in file >> cache, it is visible to other processes. >> >> 2) That rsync writes the file on the destination directly; it does >> not; it writes into a temporary file and renames that file when it is >> complete. >> > > While you=E2=80=99re correct; I never made either of those assumptions=C2= =A0 > Number 1 is irrelevant because files are sent from the master and received by the slave. Two different computers that don't share the same cache. Number 2 blows away my obscurity completely, I just didn't know that rsync works that way. It must be documented somewhere in the (very long) rsync manual. I just opened it and I looked specifically for this behaviour, but I cannot find it. 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. Although it seems logical and I believe you, but I did not want to make such assumptions either. So, problem solved in theory. The next step is to do tests by simulating network outages. I also have a proposal: let's change the example in the PostgreSQL documentation! The example archive_command presented in the docs contains a simple cp command that does not write data to temporary files. Anyone who tries to use that example on a production server will shoot himself on the foot. At least we should have a note there, telling that it is the user's responsibility to make sure that only complete WAL files appear on the slave's archive directory, and that the cp command is just a silly example that should never be used on a production server.= Thank you for your help! =C2=A0=C2=A0 Laszlo --------------C626A346606548EF920AF610 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


There seem to be 2 fundamental misunderstandings here:

1) That other processes cannot see data written to a file until it is flushed to disk; this is not true; while file data is still in file cache, it is visible to other processes.

2) That rsync writes the file on the destination directly; it does not; it writes into a temporary file and renames that file when it is complete.


While you’re correct; I never made either of those assumptions 

Number 1 is irrelevant because files are sent from the master and received by the slave. Two different computers that don't share the same cache. Number 2 blows away my obscurity completely, I just didn't know that rsync works that way. It must be documented somewhere in the (very long) rsync manual. I just opened it and I looked specifically for this behaviour, but I cannot find it. 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. Although it seems logical and I believe you, but I did not want to make such assumptions either.

So, problem solved in theory. The next step is to do tests by simulating network outages.

I also have a proposal: let's change the example in the PostgreSQL documentation! The example archive_command presented in the docs contains a simple cp command that does not write data to temporary files. Anyone who tries to use that example on a production server will shoot himself on the foot. At least we should have a note there, telling that it is the user's responsibility to make sure that only complete WAL files appear on the slave's archive directory, and that the cp command is just a silly example that should never be used on a production server.

Thank you for your help!

   Laszlo

--------------C626A346606548EF920AF610--