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

patch-3 (3-allow-wal-record-header-to-be-split.patch)WAL Format Changes

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "heikki(dot)linnakangas(at)enterprisedb(dot)com" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: patch-3 (3-allow-wal-record-header-to-be-split.patch)WAL Format Changes
Date: 2012-06-30 07:11:15
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C3828513A55@szxeml509-mbx (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
While reading patch-3 (3-allow-wal-record-header-to-be-split.patch) of
WAL Format
Changes(, I had few observations which are summarized below:

ReadRecord(XLogRecPtr *RecPtr, int emode, bool fetching_ckpt)
+ /*
+  * If we got the whole header already, validate it immediately. Otherwise
+  * we validate it after reading the rest of the header from the next page.
+  */
+ if (targetRecOff <= XLOG_BLCKSZ - SizeOfXLogRecord)
+ {
+  if (!ValidXLogRecordHeader(RecPtr, record, emode, randAccess))
+   goto next_record_is_invalid;
+  gotheader = true;
+ }
+ else
+  gotheader = false;

Shouldn't the record header validation be done before the check for allocating a bigger record buffer based
on total length. Otherwise it may lead to allocation of bigger buffer which may not be required if record header is invalid.
In cases where record header is not split, validation can be done before otherwise it can be done later.

3. General observation, not related to your changes
XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata)
        if (freespace == 0)
                 updrqst = AdvanceXLInsertBuffer(false);

In the code, AdvanceXLInsertBuffer(false); is called after starting critical section and acquiring
WALInsertLock, now if any error occurs inside  AdvanceXLInsertBuffer()
(in one of the paths it calls XLogWrite(), from which it can call XLogFileInit() where error can occur);
how will it release WALInsertLock or end critical section.

With Regards,

Amit Kapila.


pgsql-hackers by date

Next:From: Markus WannerDate: 2012-06-30 09:39:09
Subject: Re: Pruning the TODO list
Previous:From: Alex HunsakerDate: 2012-06-30 02:16:08
Subject: Re: Support for array_remove and array_replace functions

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