Обсуждение: WAL Log numbering
Hi guys,
Running 7.1.3 on Mandrake Linux 8.0.
Just noticed the numbering sequence which the WAL log used here was :
DEBUG: MoveOfflineLogs: remove 00000000000000FA
DEBUG: MoveOfflineLogs: remove 00000000000000FB
DEBUG: MoveOfflineLogs: remove 00000000000000FC
DEBUG: MoveOfflineLogs: remove 00000000000000FD
DEBUG: MoveOfflineLogs: remove 00000000000000FE
DEBUG: MoveOfflineLogs: remove 0000000100000000
DEBUG: MoveOfflineLogs: remove 0000000100000001
DEBUG: MoveOfflineLogs: remove 0000000100000002
DEBUG: MoveOfflineLogs: remove 0000000100000003
DEBUG: MoveOfflineLogs: remove 0000000100000004
DEBUG: MoveOfflineLogs: remove 0000000100000005
DEBUG: MoveOfflineLogs: remove 0000000100000006
I would have though that after 00000000000000FE would be
0000000000000100, not 0000000100000000.
Just checked through the Interactive docs (not sure which version of 7.1
they are) and says the numbers should be sequential. Just checked the
archives and didn't find anything regarding this.
Bug or not?
Regards and best wishes,
Justin Clift
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Justin Clift <justin@postgresql.org> writes:
> I would have though that after 00000000000000FE would be
> 0000000000000100, not 0000000100000000.
This is the intended behavior, I believe. The low-order half is a
32-bit byte offset DIV XLogSegSize --- we could compress out the zero
bits, but only at the cost of wiring an assumption about XLogSegSize
into the filename format. The reason that 0/FF is missing from the
sequence is stated in xlog.h:
/*
* We break each logical log file (xlogid value) into 16Mb segments.
* One possible segment at the end of each log file is wasted, to ensure
* that we don't have problems representing last-byte-position-plus-1.
*/
#define XLogSegSize ((uint32) (16*1024*1024))
#define XLogSegsPerFile (((uint32) 0xffffffff) / XLogSegSize)
#define XLogFileSize (XLogSegsPerFile * XLogSegSize)
> Just checked through the Interactive docs (not sure which version of 7.1
> they are) and says the numbers should be sequential.
This would seem to be an oversimplification in the docs.
regards, tom lane
Tom Lane wrote:
>
> Justin Clift <justin@postgresql.org> writes:
> > I would have though that after 00000000000000FE would be
> > 0000000000000100, not 0000000100000000.
>
<snip>
> > Just checked through the Interactive docs (not sure which version of 7.1
> > they are) and says the numbers should be sequential.
>
> This would seem to be an oversimplification in the docs.
Thanks Tom.
I'll see if I can get the time to generate a patch for a better
explanation.
:-)
Regards and best wishes,
Justin Clift
>
> regards, tom lane
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Attached is a patch that changes "sequential" to "ever-increasing". > Justin Clift <justin@postgresql.org> writes: > > I would have though that after 00000000000000FE would be > > 0000000000000100, not 0000000100000000. > > This is the intended behavior, I believe. The low-order half is a > 32-bit byte offset DIV XLogSegSize --- we could compress out the zero > bits, but only at the cost of wiring an assumption about XLogSegSize > into the filename format. The reason that 0/FF is missing from the > sequence is stated in xlog.h: > > /* > * We break each logical log file (xlogid value) into 16Mb segments. > * One possible segment at the end of each log file is wasted, to ensure > * that we don't have problems representing last-byte-position-plus-1. > */ > #define XLogSegSize ((uint32) (16*1024*1024)) > #define XLogSegsPerFile (((uint32) 0xffffffff) / XLogSegSize) > #define XLogFileSize (XLogSegsPerFile * XLogSegSize) > > > Just checked through the Interactive docs (not sure which version of 7.1 > > they are) and says the numbers should be sequential. > > This would seem to be an oversimplification in the docs. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 Index: doc/src/sgml/wal.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v retrieving revision 1.9 diff -c -r1.9 wal.sgml *** doc/src/sgml/wal.sgml 2001/09/09 23:52:12 1.9 --- doc/src/sgml/wal.sgml 2001/09/22 03:58:39 *************** *** 137,143 **** divided into 8 kB pages. The log record headers are described in <filename>access/xlog.h</filename>; record content is dependent on the type of event that is being logged. Segment files are given ! sequential numbers as names, starting at <filename>0000000000000000</filename>. The numbers do not wrap, at present, but it should take a very long time to exhaust the available stock of numbers. --- 137,143 ---- divided into 8 kB pages. The log record headers are described in <filename>access/xlog.h</filename>; record content is dependent on the type of event that is being logged. Segment files are given ! ever-increasing numbers as names, starting at <filename>0000000000000000</filename>. The numbers do not wrap, at present, but it should take a very long time to exhaust the available stock of numbers.
Hi Bruce, Bruce Momjian wrote: > > Attached is a patch that changes "sequential" to "ever-increasing". That's a good idea. :) I was trying to think of the right wording, but I could only think of sentences that were too complex. That one's nice and simple. Regards and best wishes, Justin Clift > > > Justin Clift <justin@postgresql.org> writes: > > > I would have though that after 00000000000000FE would be > > > 0000000000000100, not 0000000100000000. > > > > This is the intended behavior, I believe. The low-order half is a > > 32-bit byte offset DIV XLogSegSize --- we could compress out the zero > > bits, but only at the cost of wiring an assumption about XLogSegSize > > into the filename format. The reason that 0/FF is missing from the > > sequence is stated in xlog.h: > > > > /* > > * We break each logical log file (xlogid value) into 16Mb segments. > > * One possible segment at the end of each log file is wasted, to ensure > > * that we don't have problems representing last-byte-position-plus-1. > > */ > > #define XLogSegSize ((uint32) (16*1024*1024)) > > #define XLogSegsPerFile (((uint32) 0xffffffff) / XLogSegSize) > > #define XLogFileSize (XLogSegsPerFile * XLogSegSize) > > > > > Just checked through the Interactive docs (not sure which version of 7.1 > > > they are) and says the numbers should be sequential. > > > > This would seem to be an oversimplification in the docs. > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ------------------------------------------------------------------------ > Index: doc/src/sgml/wal.sgml > =================================================================== > RCS file: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v > retrieving revision 1.9 > diff -c -r1.9 wal.sgml > *** doc/src/sgml/wal.sgml 2001/09/09 23:52:12 1.9 > --- doc/src/sgml/wal.sgml 2001/09/22 03:58:39 > *************** > *** 137,143 **** > divided into 8 kB pages. The log record headers are described in > <filename>access/xlog.h</filename>; record content is dependent on > the type of event that is being logged. Segment files are given > ! sequential numbers as names, starting at > <filename>0000000000000000</filename>. The numbers do not wrap, at > present, but it should take a very long time to exhaust the > available stock of numbers. > --- 137,143 ---- > divided into 8 kB pages. The log record headers are described in > <filename>access/xlog.h</filename>; record content is dependent on > the type of event that is being logged. Segment files are given > ! ever-increasing numbers as names, starting at > <filename>0000000000000000</filename>. The numbers do not wrap, at > present, but it should take a very long time to exhaust the > available stock of numbers. -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi