Re: Page Checksums

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Page Checksums
Дата
Msg-id 74DC9138-85BA-4308-9D8D-91CEE07E8A57@nasby.net
обсуждение исходный текст
Ответ на Re: Page Checksums  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Jan 24, 2012, at 9:15 AM, Simon Riggs wrote:
> On Tue, Jan 24, 2012 at 2:49 PM, Robert Treat <rob@xzilla.net> wrote:
>>> And yes, I would for sure turn such functionality on if it were present.
>>>
>>
>> That's nice to say, but most people aren't willing to take a 50%
>> performance hit. Not saying what we end up with will be that bad, but
>> I've seen people get upset about performance hits much lower than
>> that.
> When we talk about a 50% hit, are we discussing (1) checksums that are
> checked on each I/O, or (2) checksums that are checked each time we
> re-pin a shared buffer?  The 50% hit was my estimate of (2) and has
> not yet been measured, so shouldn't be used unqualified when
> discussing checksums. Same thing is also true "I would use it"
> comments, since we're not sure whether you're voting for (1) or (2).
>
> As to whether people will actually use (1), I have no clue. But I do
> know is that many people request that feature, including people that
> run heavy duty Postgres production systems and who also know about
> filesystems. Do people need (2)? It's easy enough to add as an option,
> once we have (1) and there is real interest.

Some people will be able to take a 50% hit and will happily turn on checksumming every time a page is pinned. But I
suspecta lot of folks can't afford that kind of hit, but would really like to have their filesystem cache protected
(we'recertainly in the later camp). 

As for checksumming filesystems, I didn't see any answers about whether the filesystem *cache* was also protected by
thefilesystem checksum. Even if it is, the choice of checksumming filesystems is certainly limited... ZFS is the only
onethat seems to have real traction, but that forces you off of Linux, which is a problem  for many shops. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: lots of unused variable warnings in assert-free builds
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: PgNext: CFP