Why do we have a WAL record for CLOG page extension? - Mailing list pgsql-patches

From Simon Riggs
Subject Why do we have a WAL record for CLOG page extension?
Date
Msg-id 1149603766.2621.474.camel@localhost.localdomain
Whole thread Raw
Responses Re: Why do we have a WAL record for CLOG page extension?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: 'Index Full Scan' for Index Scan without Index Cond
Next
From: Tom Lane
Date:
Subject: Re: 'Index Full Scan' for Index Scan without Index Cond