Re: WAL Log numbering - Mailing list pgsql-bugs

From Justin Clift
Subject Re: WAL Log numbering
Date
Msg-id 3BAC7EA9.CA270E0B@postgresql.org
Whole thread Raw
In response to Re: WAL Log numbering  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: WAL Log numbering
Next
From: Justin Clift
Date:
Subject: Re: Bug #466: Unable to remove /root/tmp/initdb:xxxx.xxx