Re: Block-level CRC checks - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: Block-level CRC checks
Date
Msg-id 36e682920812150903s44faf0a4t6623562707d70133@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Mon, Dec 15, 2008 at 11:50 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> That only does heap hint bits, but it does nothing about pd_flags, the
> btree flags (btpo_cycleid I think), and something else I don't recall at
> the moment.  This was all solvable however.  The big problem with it was
> that it was using a new bit in pd_flags in unsafe ways.  To make it safe
> you'd have to grab a lock on the page, which is very probably problematic.

:(

>> Now, in the case where hint bits have been updated and a WAL record is
>> required because the buffer is being flushed, requiring the WAL to be
>> flushed up to that point may be a killer on performance.  Has anyone
>> tested it?
>
> I didn't measure it but I'm sure it'll be plenty slow.

Yeah.  What really sucks is that it would be fairly unpredictable and
could easily result in unexpected production performance issues.

It is pretty late in the process to continue with this design-related
discussion, but I really wanted to see it in 8.4.

-- 
Jonah H. Harris, Senior DBA
myYearbook.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Block-level CRC checks
Next
From: "Robert Haas"
Date:
Subject: Re: Restore enforce_generic_type_consistency's breaks a farms