Re: Cost of XLogInsert CRC calculations

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Cost of XLogInsert CRC calculations
Дата
Msg-id 873bv6anhq.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Cost of XLogInsert CRC calculations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Simon Riggs <simon@2ndquadrant.com> writes:
> 
> > For (1), records are so short that probably CRC16 would be sufficient
> > without increasing the error rate noticeably.
> 
> The control files are so short that CRC16 would be plenty.

It's not really the size of the data that governs the reasonable size of the
CRC. It's the probability of there being errors. For that you have to think
about what possible causes of errors you're concerned with.

AFAIK there's no CRC check at all in tables or indexes. So it doesn't seem
like bad hardware like a bad drive or RAM is what you're concerned with here.

From the other post it sounded like the threat was the possibility of an
interrupted arriving after the transaction commit log entry is written but
before the fsync has written the rest of the log.

In that case it seems the probability of it occurring is independent of the
size of the log entry. Is a 1 in 64k chance of a power failure resulting in
data corruption acceptable? A 1 in 4 billion chance?

You could eliminate the hole completely by using two fsyncs. fsync the
transaction information once. Then once that completes, then write and fsync
the transaction commit log entry.

-- 
greg



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Cost of XLogInsert CRC calculations
Следующее
От: David Fetter
Дата:
Сообщение: Best practices: MERGE