Are there any TODO items here?
---------------------------------------------------------------------------
On Mon, Sep 12, 2011 at 09:36:02PM +0300, Peter Eisentraut wrote:
> 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
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +