Skip site navigation (1) Skip section navigation (2)

Re: WAL Log numbering

From: Justin Clift <justin(at)postgresql(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: WAL Log numbering
Date: 2001-09-22 12:06:01
Message-ID: 3BAC7EA9.CA270E0B@postgresql.org (view raw or flat)
Thread:
Lists: 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(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)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

In response to

pgsql-bugs by date

Next:From: Justin CliftDate: 2001-09-22 14:58:14
Subject: Re: Bug #466: Unable to remove /root/tmp/initdb:xxxx.xxx
Previous:From: Vince VielhaberDate: 2001-09-22 05:12:27
Subject: Re: Website, mailing list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group