Isn't the naming of the xlog files slightly bogus? We have the following sequence:
00000001000008D0000000FD 00000001000008D0000000FE 00000001000008D100000000 Ignoring that we skip FF for some obscure reason (*), these are effectively supposed to be 64-bit numbers, chunked into 16MB pieces, so shouldn't the naming be 00000001000008D0FD000000 00000001000008D0FE000000 00000001000008D100000000 Then a lot of other things would also start making more sense: The backup file 00000001000008D1000000C9.00013758.backup should really be 00000001000008D1C9013758.backup (At least conceptually. It's debatable whether we'd want to change that, since as it is, it's convenient to detect the preceding WAL file name by cutting off the end. OTOH, it's safer to actually look into the backup file for that information.) The return value of pg_start_backup that currently looks something like pg_start_backup ----------------- 8D1/C9013758 should really be 000008D1C9013758 (perhaps the timeline should be included?) and similarly, log output and pg_controldata output like Latest checkpoint location: 8D3/5A1BB578 should be Latest checkpoint location: 000008D35A1BB578 Then all instances of xlog location would look the same. Also, the documentation offers this example: "For example, if the starting WAL file is 0000000100001234000055CD the backup history file will be named something like 0000000100001234000055CD.007C9330.backup." Both the WAL and the backup file names used here are actually impossible, and are not helping to clarify the issue. It seems to me that this is all uselessly complicated and confused. (*) - That idea appears to come from the same aboriginal confusion about WAL "files" vs "segments" vs WAL position. Unless we support WAL segments of size 1 or 2 bytes, there shouldn't be any risk of overflowing the segment counter. PS2: While we're discussing the cleanup of xlog.c, someone daring could replace XLogRecPtr by a plain uint64 and possibly save hundres of lines of code and eliminate a lot of the above confusion. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers