On Mon, Jun 18, 2012 at 2:08 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 18.06.2012 21:00, Robert Haas wrote: >> On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund<and...@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.
Ugh. Well, that's a good reason for thinking twice before changing it, if not abandoning the idea altogether. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
