On 02.05.2013 08:16, Amit Langote wrote:
> I was just going through the xlog.c and I came across following which
> confused me:
>
> Given,
>
> src/include/access/xlogdefs.h
>
> #define XLogSegsPerFile (((uint32) 0xffffffff) / XLogSegSize)
> #define XLogFileSize (XLogSegsPerFile * XLogSegSize)
>
> Also,
> typedef struct XLogRecPtr
> {
> uint32 xlogid; /* log file #, 0 based */
> uint32 xrecoff; /* byte offset of location
> in log file */
> } XLogRecPtr;
>
>
> Check for crossing of xlog "segment" boundary?
>
> src/include/access/trasam/xlog.c
>
> /* Check for crossing of xlog segment boundary */
> if (RecPtr->xrecoff>= XLogFileSize)
> {
> (RecPtr->xlogid)++;
> RecPtr->xrecoff = 0;
> }
>
> Is that xlog "file" boundary or am I missing something?
The WAL space is divided into 4GB "log files", which are not physical
files but purely logical constructs. The XLogRecPtr.xlogid field
indicates the logical log file, and xrecoff is the offset within the
file. Each logical log file is divided into "log segments", which are
the physical files you see in pg_xlog. See also the comment above the
definition of XLogRecPtr.
This split was necessary to deal with more than 4 GB of WAL, using only
32-bit integers. In 9.3, that's changed, and XLogRecPtr is a 64-bit
integer. The whole concept of "logical log files" is gone, so it's a lot
less confusing now.
- Heikki