On Mon, Jun 18, 2012 at 2:08 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> 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.
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
