Re: Checkpoint cost, looks like it is WAL/CRC

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Checkpoint cost, looks like it is WAL/CRC
Дата
Msg-id 1120721436.3940.227.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Checkpoint cost, looks like it is WAL/CRC  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Checkpoint cost, looks like it is WAL/CRC  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Thu, 2005-07-07 at 00:29 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruno Wolff III <bruno@wolff.to> writes:
> > > Are you sure about that? That would probably be the normal case, but are
> > > you promised that the hardware will write all of the sectors of a block
> > > in order?
> > 
> > I don't think you can possibly assume that.  If the block crosses a
> > cylinder boundary then it's certainly an unsafe assumption, and even
> > within a cylinder (no seek required) I'm pretty sure that disk drives
> > have understood "write the next sector that passes under the heads"
> > for decades.
> 
> SCSI tagged queueing certainly allows 512-byte blocks to be reordered
> during writes.

Then a torn-page tell-tale is required that will tell us of any change
to any of the 512-byte sectors that make up a block/page.

Here's an idea:

We read the page that we would have backed up, calc the CRC and write a
short WAL record with just the CRC, not the block. When we recover we
re-read the database page, calc its CRC and compare it with the CRC from
the transaction log. If they differ, we know that the page was torn and
we know the database needs recovery. (So we calc the CRC when we log AND
when we recover).

This avoids the need to write full pages, though slightly slows down
recovery.

Best Regards, Simon Riggs



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Checkpoint cost, looks like it is WAL/CRC
Следующее
От: Koichi Suzuki
Дата:
Сообщение: A couple of patches for PostgreSQL 64bit support