Re: Page Checksums + Double Writes
От | Robert Haas |
---|---|
Тема | Re: Page Checksums + Double Writes |
Дата | |
Msg-id | CA+TgmoZ_iaHLCrzzXNE0mrRf585+dxqV8pLsda_w5DAgbBWB6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Page Checksums + Double Writes (Jignesh Shah <jkshah@gmail.com>) |
Ответы |
Re: Page Checksums + Double Writes
|
Список | pgsql-hackers |
On Thu, Dec 22, 2011 at 1:50 PM, Jignesh Shah <jkshah@gmail.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
В списке pgsql-hackers по дате отправления: