Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Block-level CRC checks
- From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
- To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
- Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
- Subject: Re: Block-level CRC checks
- Date: Mon, 30 Nov 2009 22:27:54 +0200
- Message-id: <4B142ACA.3070409@enterprisedb.com> <text/plain>
Simon Riggs wrote: > Proposal > > * We reserve enough space on a disk block for a CRC check. When a dirty > block is written to disk we calculate and annotate the CRC value, though > this is *not* WAL logged. Imagine this: 1. A hint bit is set. It is not WAL-logged, but the page is dirtied. 2. The buffer is flushed out of the buffer cache to the OS. A new CRC is calculated and stored on the page. 3. Half of the page is flushed to disk (aka torn page problem). The CRC made it to disk but the flipped hint bit didn't. You now have a page with incorrect CRC on disk. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
- Follow-Ups:
- Re: Block-level CRC checks
- From: Simon Riggs
- Re: Block-level CRC checks
- References:
- Re: Block-level CRC checks
- From: Simon Riggs
- Re: Block-level CRC checks
- Prev by Date: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
- Next by Date: Re: Application name patch - v4
- Previous by thread: Re: Block-level CRC checks
- Next by thread: Re: Block-level CRC checks
- Indexes: