Re: 16-bit page checksums for 9.2

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: 16-bit page checksums for 9.2
Дата
Msg-id CA+U5nM+iMQkJCxEdRNr7R0Sv9SnT21XjYbv-oxSEd9bngxRkpw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: 16-bit page checksums for 9.2  (Andres Freund <andres@anarazel.de>)
Re: 16-bit page checksums for 9.2  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Thu, Jan 5, 2012 at 3:46 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:

>> Sure.  I just think you are there already except for what I got into.

> New version attached, with your suggested changes included. Hole check
> code is there as well, but ifdef'd out since it isn't a valid check in
> all cases.

Following private discussions, Kevin showed me the patch at v3 was
inadequate because it didn't cater for torn pages as a result of hint
bit writes.

The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been changed. IMHO this fixes the torn page problem
correctly, though at some additional loss of performance but not the
total catastrophe some people had imagined. Specifically we don't need
to log anywhere near 100% of hint bit settings, much more like 20-30%
(estimated not measured).

Dan Scales also observed some cases where private writes aren't
checksummed, e.g. index build. Those suggestions are still outstanding
from me, but the v4 is worthy of more serious review.

I'll now turn my attention more fully onto the DW patch.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Poorly thought out code in vacuum
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Progress on fast path sorting, btree index creation time