From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jignesh Shah <jkshah(at)gmail(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org> |
Subject: | Re: Page Checksums + Double Writes |
Date: | 2011-12-22 20:04:48 |
Message-ID: | CA+TgmoZ_iaHLCrzzXNE0mrRf585+dxqV8pLsda_w5DAgbBWB6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 22, 2011 at 1:50 PM, Jignesh Shah <jkshah(at)gmail(dot)com> wrote:
> In the double write implementation, every checkpoint write is double
> writed,
Unless I'm quite thoroughly confused, which is possible, the double
write will need to happen the first time a buffer is written following
each checkpoint. Which might mean the next checkpoint, but it could
also be sooner if the background writer kicks in, or in the worst case
a buffer has to do its own write.
Furthermore, we can't *actually* write any pages until they are
written *and fsync'd* to the double-write buffer. So the penalty for
the background writer failing to do the right thing is going to go up
enormously. Think about VACUUM or COPY IN, using a ring buffer and
kicking out its own pages. Every time it evicts a page, it is going
to have to doublewrite the buffer, fsync it, and then write it for
real. That is going to make PostgreSQL 6.5 look like a speed demon.
The background writer or checkpointer can conceivably dump a bunch of
pages into the doublewrite area and then fsync the whole thing in
bulk, but a backend that needs to evict a page only wants one page, so
it's pretty much screwed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-12-22 20:19:16 | Re: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation |
Previous Message | Robert Haas | 2011-12-22 19:54:00 | Re: Review: Non-inheritable check constraints |