Why do we have a WAL record for CLOG page extension?

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

Responses

Browse pgsql-patches by date

  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