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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
