On Thu, Dec 29, 2011 at 11:08:43AM -0600, Kevin Grittner wrote: > > Heikki Linnakangas wrote: > > Simon Riggs wrote: > > >> OK, then we are talking at cross purposes. Double write buffers, > >> in the way you explain them allow us to remove full page writes. > >> They clearly don't do anything to check page validity on read. > >> Torn pages are not the only fault we wish to correct against... > >> and the double writes idea is orthogonal to the idea of checksums. > > > > The reason we're talking about double write buffers in this thread > > is that double write buffers can be used to solve the problem with > > hint bits and checksums.
> Of course, it will be a big plus if we can roll this out in 9.2 in > conjunction with a double-write feature. Not only will double-write > probably be a bit faster than full_page_writes in the WAL log, but it > will allow protection against torn pages on hint-bit-only writes > without adding those writes to the WAL or doing any major > rearrangement of where they sit that would break pg_upgrade. [Thanks for your recent thread summaries.] A double-write buffer, like a WAL-logged full-page image, is a technique for performing atomic writes wider than those automatically provided by components further down the storage stack. The two strategies have different performance characteristics, and we're told that a double-write buffer would better serve us overall. However, its benefits would not be *greater* for hint-only writes than for any other write. For that reason, I think we should consider these changes independently. With page checksums enabled, remove the hazard of torn hint-only writes by ensuring that a WAL FPI has flushed since the last checkpoint. When necessary, emit an FPI-only record. Separately, optimize first-since-checkpoint writes by replacing FPIs with double-write buffers. The double-write patch will reduce the added WAL of the checksum/safe-hint-updates patch to zero. If the double-writes patch founders, we'll just have more-costly, yet equally reliable, page checksums. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
