From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | Why do we have a WAL record for CLOG page extension? |
Date: | 2006-06-06 14:22:46 |
Message-ID: | 1149603766.2621.474.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Why do we have a WAL record for CLOG page extension? It seems to be
unnecessary, since other code already covers that failure situation.
We ignore heap extensions, on the assumption that the insertion will
automatically extend the relation when we recover. We also ignore
previously truncated clog pages, so the absence of a clog page at
recovery time is clearly not an issue. So why not avoid writing WAL when
we move to the next clog page and fix this at recovery time if it is an
issue?
Well, slru.c *already* includes code that specifically ignores errors
for set/get TransactionIds during recovery when pages are absent, plus
this is supposed to still work even if this is not the first page of a
clog segment. So, the WAL record seems like it is not required.
Patch removes the xlog record written at new page time. This ensures
that we don't need to wait for an I/O when holding the XidGenLock, which
can be a problem with hundreds of people requesting that lock,
especially since we may need to queue for one of the WAL locks first.
Leave the RMID for clog, in case required later.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
no_log_clog.patch | text/x-patch | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-06 14:27:53 | Re: fillfactor using WITH syntax |
Previous Message | Tom Lane | 2006-06-06 14:02:19 | Re: 'Index Full Scan' for Index Scan without Index Cond |