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 1f0V5X-0005Dk-R6 for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Mar 2018 16:35:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f0V5W-0007ps-TO for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Mar 2018 16:35:14 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0V5W-0007ow-M3 for pgsql-hackers@lists.postgresql.org; Mon, 26 Mar 2018 16:35:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0V5S-0001fp-6h for pgsql-hackers@lists.postgresql.org; Mon, 26 Mar 2018 16:35:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w2QGYQif030465; Mon, 26 Mar 2018 12:34:26 -0400 From: Tom Lane To: Chapman Flack cc: pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility In-reply-to: <5AB8D9C2.2010208@anastigmatix.net> References: <5A92F0C0.7070706@anastigmatix.net> <5AADB130.2020206@anastigmatix.net> <4597.1521338981@sss.pgh.pa.us> <46FFB930-B0F3-400A-85ED-D9948C97FADF@yesql.se> <5AAEE00E.9050503@anastigmatix.net> <21C25ED8-4ED8-4AD4-B551-3E3987ECB18F@yesql.se> <5AAEFF11.3070903@anastigmatix.net> <20180326032731.GM24540@tamriel.snowman.net> <5AB8D9C2.2010208@anastigmatix.net> Comments: In-reply-to Chapman Flack message dated "Mon, 26 Mar 2018 07:30:10 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30463.1522082066.1@sss.pgh.pa.us> Date: Mon, 26 Mar 2018 12:34:26 -0400 Message-ID: <30464.1522082066@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Chapman Flack writes: > On 03/25/18 23:27, Stephen Frost wrote: >> AdvanceXLInsertBuffer() does quite a bit, so I'm a bit surprised to see >> this simply removing that call, you're confident there's nothing done >> which still needs doing..? > My belief from looking at the code was that AdvanceXLInsertBuffer() is among > the things GetXLogBuffer() does, so calling both would result in two calls > to the former (which I don't believe would hurt, it would only > do enough work the second time to determine it had already been done). If that's the argument, why is the WALInsertLockUpdateInsertingAt(CurrPos) call still there? GetXLogBuffer() would do that too. In any case, the new comment seems very poorly written, as it fails to explain what's going on, and the reference to a function that is not actually called from the vicinity of the comment doesn't help. I'd suggest something like "GetXLogBuffer() will fetch and initialize the next WAL page for us. But it initializes the page header to nonzero, which is undesirable because X, so we then reset the header to zero". It might also be worth explaining how you know that the new page's header is short not long. regards, tom lane