Re: Checkpoint cost, looks like it is WAL/CRC
| От | Tom Lane |
|---|---|
| Тема | Re: Checkpoint cost, looks like it is WAL/CRC |
| Дата | |
| Msg-id | 12626.1120830464@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Checkpoint cost, looks like it is WAL/CRC (Simon Riggs <simon@2ndquadrant.com>) |
| Ответы |
Re: Checkpoint cost, looks like it is WAL/CRC
|
| Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes:
> Is there also a potential showstopper in the redo machinery? We work on
> the assumption that the post-checkpoint block is available in WAL as a
> before image. Redo for all actions merely replay the write action again
> onto the block. If we must reapply the write action onto the block, the
> redo machinery must check to see whether the write action has already
> been successfully applied before it decides to redo. I'm not sure that
> the current code does that.
The redo machinery relies on the page LSN to tell whether the update has
occurred. In the presence of torn pages, that's of course unreliable.
> Having raised that objection, ISTM that checking for torn pages can be
> accomplished reasonably well using a few rules...
I have zero confidence in this; the fact that you can think of
(incomplete, inaccurate) heuristics for heap-page operations doesn't
mean you can make it work for indexes.
regards, tom lane
В списке pgsql-hackers по дате отправления: