Why do we have a WAL record for CLOG page extension?
| От | Simon Riggs |
|---|---|
| Тема | Why do we have a WAL record for CLOG page extension? |
| Дата | |
| Msg-id | 1149603766.2621.474.camel@localhost.localdomain обсуждение исходный текст |
| Ответы |
Re: Why do we have a WAL record for CLOG page extension?
|
| Список | 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
Вложения
В списке pgsql-patches по дате отправления: