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

Regarding WAL Format Changes

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Regarding WAL Format Changes
Date: 2012-06-27 14:14:29
Message-ID: 008701cd546f$2af3b490$80db1db0$@kapila@huawei.com (view raw or flat)
Thread:
Lists: pgsql-hackers
While reading patch-1 (
<http://archives.postgresql.org/pgsql-hackers/2012-06/txtFskHiYakjO.txt>
1-use-uint64-got-segno.patch) of WAL Format
Changes(http://archives.postgresql.org/message-id/4FDA5136.6080206@enterpris
edb.com), I had few observations which are summarized below:

 

1. Function header for following functions still contains referece to log,
seg 
   a. InstallXLogFileSegment() 
   b. RemoveOldXlogFiles() 
   c. XLogFileCopy() 
   d. XLogGetLastRemoved() 
   e. UpdateLastRemovedPtr() 
   f. RemoveOldXlogFiles() 

2. @@ -2680,8 +2645,8 @@ InstallXLogFileSegment(uint32 *log, uint32 *seg,
char *tmppath, 
                         LWLockRelease(ControlFileLock); 
                 ereport(LOG, 
                                 (errcode_for_file_access(), 
-                                 errmsg("could not link file \"%s\" to
\"%s\" (initialization of log file %u, segment %u): %m", 
-                                                tmppath, path, *log,
*seg))); 
+                                 errmsg("could not link file \"%s\" to
\"%s\" (initialization of log file): %m", 
+                                                tmppath, path))); 
   If Changed error message can contain log file and segment number, it
would be more clear. That should be easily 
   deducible from segment number. 

3.   -RemoveOldXlogFiles(uint32 log, uint32 seg, XLogRecPtr endptr) 
+RemoveOldXlogFiles(XLogSegNo segno, XLogRecPtr endptr) 
. 
. 
.
@@ -4016,8 +3953,9 @@ retry: 
                         if (!(((XLogPageHeader) readBuf)->xlp_info &
XLP_FIRST_IS_CONTRECORD)) 
                         { 
                                 ereport(emode_for_corrupt_record(emode,
*RecPtr), 
-                                                (errmsg("there is no
contrecord flag in log file %u, segment %u, offset %u", 
-                                                                readId,
readSeg, readOff))); 
+                                                (errmsg("there is no
contrecord flag in log segment %s, offset %u", 
+
XLogFileNameP(curFileTLI, readSegNo), 
+                                                                readOff)));

                                 goto next_record_is_invalid; 
                         } 
                         pageHeaderSize =
XLogPageHeaderSize((XLogPageHeader) readBuf); 
@@ -4025,10 +3963,13 @@ retry: 
                         if (contrecord->xl_rem_len == 0 || 
                                 total_len != (contrecord->xl_rem_len +
gotlen)) 
                         { 
+                                char fname[MAXFNAMELEN]; 
+                                XLogFileName(fname, curFileTLI, readSegNo);

                                 ereport(emode_for_corrupt_record(emode,
*RecPtr), 
-                                                (errmsg("invalid contrecord
length %u in log file %u, segment %u, offset %u", 
+                                                (errmsg("invalid contrecord
length %u in log segment %s, offset %u", 
 
contrecord->xl_rem_len, 
-                                                                readId,
readSeg, readOff))); 
+
XLogFileNameP(curFileTLI, readSegNo), 
+                                                                readOff)));

                                 goto next_record_is_invalid; 
                         } 
      
  For the above 2 changed error messages, 'log segment' is used for
filename. 
  However all similar changes has 'log file' for filename. There are some
places 
  where 'log segment' is used and other places it is 'log file'. 
  So is there any particular reason for it? 
  
  
4. @@ -533,33 +533,17 @@ pg_xlog_location_diff(PG_FUNCTION_ARGS)
-        /* 
-         * Sanity check 
-         */ 
-        if (loc1.xrecoff > XLogFileSize) 
-                ereport(ERROR, 
-                                (errcode(ERRCODE_INVALID_PARAMETER_VALUE), 
-                                 errmsg("xrecoff \"%X\" is out of valid
range, 0..%X", loc1.xrecoff, XLogFileSize))); 
-        if (loc2.xrecoff > XLogFileSize) 
-                ereport(ERROR, 
-                                (errcode(ERRCODE_INVALID_PARAMETER_VALUE), 
-                                 errmsg("xrecoff \"%X\" is out of valid
range, 0..%X", loc2.xrecoff, XLogFileSize))); 
+        bytes1 = (((uint64)loc1.xlogid) << 32L) + loc1.xrecoff; 
+        bytes2 = (((uint64)loc2.xlogid) << 32L) + loc2.xrecoff; 

    Is there no chance that it can be out of valid range after new changes,
just a doubt? 
    
    
5. 
--- a/src/backend/replication/walreceiver.c 
+++ b/src/backend/replication/walreceiver.c 
@@ -69,11 +69,12 @@ walrcv_disconnect_type walrcv_disconnect = NULL; 
  
 /* 
  * These variables are used similarly to openLogFile/Id/Seg/Off, 
- * but for walreceiver to write the XLOG. 
+ * but for walreceiver to write the XLOG. recvFileTLI is the TimeLineID 

In the above comments, there is still reference to Id/Seg/Off.

 

 

With Regards,

Amit Kapila.

 

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-27 14:14:33
Subject: Re: Reporting hba lines
Previous:From: Andrew DunstanDate: 2012-06-27 14:07:33
Subject: Re: warning handling in Perl scripts

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