Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C9878720082 for ; Mon, 14 Nov 2011 06:18:04 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 35483-01 for ; Mon, 14 Nov 2011 10:17:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from mail.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by mail.postgresql.org (Postfix) with ESMTP id E8628720081 for ; Mon, 14 Nov 2011 06:17:58 -0400 (AST) Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by mail.archonet.com (Postfix) with ESMTP id 948697C029; Mon, 14 Nov 2011 10:17:58 +0000 (GMT) Message-ID: <4EC0EAD6.9010302@archonet.com> Date: Mon, 14 Nov 2011 10:17:58 +0000 From: Richard Huxton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Sergey Konoplev CC: Stephen Frost , Anibal David Acosta , pgsql-performance@postgresql.org Subject: Re: unlogged tables References: <005501cca0ad$b9478440$2bd68cc0$@devshock.com> <20111111201822.GN24234@tamriel.snowman.net> <4EC0D827.8090601@archonet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.918 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RDNS_DYNAMIC=0.982 X-Spam-Level: X-Archive-Number: 201111/159 X-Sequence-Number: 45670 On 14/11/11 10:08, Sergey Konoplev wrote: > On 14 November 2011 12:58, Richard Huxton wrote: >> Because they bypass the transaction-log (WAL), hence unlogged. >> There's no way to know whether there were partial updates applied when the >> system restarts. > > I probably did not understand the "truncate" meaning correct. It > truncates all the records of the table or several recent records only? All. Let's say you were doing something like "UPDATE unlogged_table SET x=1 WHERE y=2". If a crash occurs during this command, there's no guarantee that the affected disk pages were all updated. Worse, a single page might be partially updated or even have rubbish in it (depending on the nature of the crash). Without the WAL there's no way to check whether the table is good or not, or even to know what the last updates were. So - the only safe thing to do is truncate the unlogged tables. In the event of a normal shutdown, we can flush all the writes to disk so we know all the data has been written, so there is no need to truncate. -- Richard Huxton Archonet Ltd