From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tackling full page writes |
Date: | 2011-05-27 19:02:53 |
Message-ID: | BANLkTikyPcOFyC-QvsceOfa=978_qkCFCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 26, 2011 at 12:38 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, May 26, 2011 at 1:18 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> The replay of the WAL record for A doesn't rely on the content of chunk 1
>>> which B modified. So I don't think that "partial page writes" has such
>>> a problem.
>>> No?
>>
>> Sorry. WAL records today DO rely on the prior state of the page. If
>> they didn't, we wouldn't need full page writes. They don't rely on
>> them terribly heavily - things like where pd_upper is pointing, and
>> what the page LSN is. But they do rely on them.
>
> Yeah, I'm sure that normal WAL record (neither full page writes nor
> "partial page writes") relies on the prior state of the page. But WAL
> record for A is "partial page writes", which also relies on the prior
> state?
Yeah, that's how it shakes out. The idea is you have to write the
parts of the page that you rely on, but not the rest - which in turn
guarantees that those parts (but not the rest) will be correct when
you read them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-05-27 20:43:28 | storing TZ along timestamps |
Previous Message | Ross J. Reedstrom | 2011-05-27 18:57:04 | Re: tackling full page writes |