Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 1D41013FA3D7 for ; Mon, 18 Jun 2012 15:46:10 -0300 (ADT) Received: from moutng.kundenserver.de ([212.227.17.10]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sggxk-0007cm-Ap for pgsql-hackers@postgresql.org; Mon, 18 Jun 2012 18:46:09 +0000 Received: from awork2.localnet (p5DDC5F29.dip.t-dialin.net [93.220.95.41]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M0v2R-1RlqBR37mh-00uyNV; Mon, 18 Jun 2012 20:45:55 +0200 From: Andres Freund Organization: 2ndquadrant.com To: Heikki Linnakangas Subject: Re: WAL format changes Date: Mon, 18 Jun 2012 20:45:53 +0200 User-Agent: KMail/1.13.7 (Linux/3.4.0-andres; KDE/4.8.3; x86_64; ; ) Cc: pgsql-hackers@postgresql.org, Robert Haas References: <4FDA5136.6080206@enterprisedb.com> <201206182013.12868.andres@2ndquadrant.com> <4FDF7456.9010709@enterprisedb.com> In-Reply-To: <4FDF7456.9010709@enterprisedb.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206182045.53962.andres@2ndquadrant.com> X-Provags-ID: V02:K0:ASJEei3Up3L3vQSNoIqFjyu8u//y8F7JlVTVOUFVUqo /ZFHWTESe06zKV5Q/DyCRX4NXxcWts/ayfZHvMHwpyG0sUzr0H tYUmhYNgbKD7gdpa10Y5+vH1e64TsROBzJ1Zng9G/UfUlr559v rvT8LeufvF1SrxvhUfLGVF5zseUd4cGpe5Rl/wAdqwfv7b9qis INISb9h+d8BskSRl6+G3QbzAMdnULHwOq0QJ/hCaClDJoW8q/J WWn6lc1R6OHTpx7zwdn4fQKjrJKmPTBb47AGDO39ljkUHnaDql q5/3oh+MvuVZlMtD2O4rEXFp+VBW2tkBPKe+LW7KZqZaOEDcr9 e611lWEkKxw6sdiYNf71ytHq9VKspoVZJSu2/3f1F X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/916 X-Sequence-Number: 209756 On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote: > On 18.06.2012 21:13, Andres Freund wrote: > > On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote: > >> The page header contains an XLogRecPtr (LSN), so if we change it we'll > >> have to deal with pg_upgrade. I guess we could still keep XLogRecPtr > >> around as the on-disk representation, and convert between the 64-bit > >> integer and XLogRecPtr in PageGetLSN/PageSetLSN. I can try that out - > >> many xlog calculations would admittedly be simpler if it was an uint64. > > > > I am out of my depth here, not having read any of the relevant code, but > > couldn't we simply replace the lsn from disk with InvalidXLogRecPtr > > without marking the page dirty? > > > > There is the valid argument that you would loose some information when > > pages with hint bits are written out again, but on the other hand you > > would also gain the information that it was a hint-bit write... > > Sorry, I don't understand that. Where would you "replace the LSN from > disk with InvalidXLogRecPtr" ? (and no, it probably won't work ;-) ) In ReadBuffer_common or such, after reading a page from disk and verifying that the page has a valid header it seems to be possible to replace pd_lsn *in memory* by InvalidXLogRecPtr without marking the page dirty. If the page isn't modified the lsn on disk won't be changed so you don't loose debugging information in that case. If will be zero if it has been written by a hint-bit write and thats arguable a win. Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services