On fre, 2012-06-15 at 00:01 +0300, Heikki Linnakangas 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.
A thought on this. There were some concerns that this would silently break tools that pretend to have detailed knowledge of WAL file numbering and this previous behavior of skipping the FF files. We could address this by "fixing" the overall file naming from something like 00000001000008D0000000FD 00000001000008D0000000FE 00000001000008D0000000FF 00000001000008D100000000 to 00000001000008D0FD000000 00000001000008D0FE000000 00000001000008D0FF000000 00000001000008D100000000 which represents the new true WAL stream numbering as opposed to the old two-part numbering. Thus, any tool that thinks it knows how the WAL files are sequenced will break very obviously, but any tool that just looks for 24 hexadecimal digits will be fine. I wonder if any tools in the former category would also break if one changes XLOG_SEG_SIZE. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
