Re: WAL format changes
От | Heikki Linnakangas |
---|---|
Тема | Re: WAL format changes |
Дата | |
Msg-id | 4FDF6E8E.4080900@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: WAL format changes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: WAL format changes
Re: WAL format changes Re: WAL format changes |
Список | pgsql-hackers |
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: