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 1iY7wb-0004Ds-0W for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Nov 2019 12:21:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iY7wZ-0007m9-Pw for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Nov 2019 12:21:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iY7wY-0007jG-Md for pgsql-hackers@lists.postgresql.org; Fri, 22 Nov 2019 12:21:47 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iY7wQ-00060X-Mc for pgsql-hackers@postgresql.org; Fri, 22 Nov 2019 12:21:46 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B1B24890; Fri, 22 Nov 2019 07:21:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 22 Nov 2019 07:21:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=NTORl/1+52r8HHVusm1smG65GtPzXOKQF4OI+AJsl hw=; b=cX+WDKzEsGsC1sC9LKkLjh/QKFLRE4gllJvE1MoOnMqA59HIWOIPJGiuP /NMyJek/F+QPpZFVHO7h3+KLoM/Raip80eAg/9PGd9nIlGqSsY4oCCiDv0X8nwNb 3XsV1Scqema3Q1P19tDB2Zue+rmQ3HALnNUIFkCJ3nToSJf6B++pNHOa7KCIxBgw Fv/nBOKzTHb4s5ib6ndF/0T9OhjClqipC4FcuGEHqi/gQjmZj8pzL3RHUx56YWAj 37if4XbxoDB+0mMUF2jht/kff5NeXUfqpubfivcp2UhvkSwPIrVFPqamF4Ywcs63 TocCPRf9g0BrM3tvOIXXQ1opdkvCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehgedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnug hquhgrughrrghnthdrtghomheqnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgt ohhmnecukfhppeelfedrvdegvddrudegjedrjeelnecurfgrrhgrmhepmhgrihhlfhhroh hmpehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from april.pezone.net (p5df2934f.dip0.t-ipconnect.de [93.242.147.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 8648D3060061; Fri, 22 Nov 2019 07:21:32 -0500 (EST) Subject: Re: [HACKERS] WAL logging problem in 9.4.3? To: Robert Haas , Kyotaro Horiguchi References: <20190828.154210.204505676.horikyota.ntt@gmail.com> <20191025.131251.322449872063947371.horikyota.ntt@gmail.com> Cc: Noah Misch , PostgreSQL-development , Dmitry Dolgov <9erthalion6@gmail.com>, Andrew Dunstan , hlinnaka , Michael Paquier From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <1f9a76fe-6f77-eb5f-9292-9b1c92f4f5bd@2ndquadrant.com> Date: Fri, 22 Nov 2019 13:21:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-11-05 22:16, Robert Haas wrote: > First, I'd like to restate my understanding of the problem just to see > whether I've got the right idea and whether we're all on the same > page. When wal_level=minimal, we sometimes try to skip WAL logging on > newly-created relations in favor of fsync-ing the relation at commit > time. How useful is this behavior, relative to all the effort required? Even if the benefit is significant, how many users can accept running with wal_level=minimal and thus without replication or efficient backups? Is there perhaps an alternative approach involving unlogged tables to get a similar performance benefit? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services