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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
