From: Andres Freund <andres@2ndquadrant.com>
Organization: 2ndquadrant.com
To: pgsql-hackers@postgresql.org
Subject: Re: WAL format changes
Date: Mon, 18 Jun 2012 20:13:12 +0200
User-Agent: KMail/1.13.7 (Linux/3.4.0-andres; KDE/4.8.3; x86_64; ; )
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Robert Haas <robertmhaas@gmail.com>
References: <4FDA5136.6080206@enterprisedb.com>
	<CA+TgmobG9VWWvLXeK0XOxoWXtza8JTFgSu2eoAtVFucxH6gLBw@mail.gmail.com>
	<4FDF6E8E.4080900@enterprisedb.com>
In-Reply-To: <4FDF6E8E.4080900@enterprisedb.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201206182013.12868.andres@2ndquadrant.com>

On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:00, Robert Haas wrote:
> > On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund<andres@2ndquadrant.com>  
wrote:
> >>> 1. Use a 64-bit segment number, instead of the log/seg combination. And
> >>> don't waste the last segment on each logical 4 GB log file. The concept
> >>> of a "logical log file" is now completely gone. XLogRecPtr is
> >>> unchanged, but it should now be understood as a plain 64-bit value,
> >>> just split into two 32-bit integers for historical reasons. On disk,
> >>> this means that there will be log files ending in FF, those were
> >>> skipped before.
> >> 
> >> Whats the reason for keeping that awkward split now? There aren't that
> >> many users of xlogid/xcrecoff and many of those would be better served
> >> by using helper macros.
> > 
> > I wondered that, too.  There may be a good reason for keeping it split
> > up that way, but we at least oughta think about it a bit.
> 
> 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...

Greetings,

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services