From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tackling full page writes |
Date: | 2011-05-25 12:34:16 |
Message-ID: | BANLkTikskbNumu0p0XRghtF0KjuJH290DA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 24, 2011 at 10:52 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
>> As I think about it a bit more, we'd
>> need to XLOG not only the parts of the page we actually modifying, but
>> any that the WAL record would need to be correct on replay.
>
> I don't understand that statement. Can you clarify?
I'll try. Suppose we have two WAL records A and B, with no
intervening checkpoint, that both modify the same page. A reads chunk
1 of that page and then modifies chunk 2. B modifies chunk 1. Now,
suppose we make A do a "partial page write" on chunk 2 only, and B do
the same for chunk 1. At the point the system crashes, A and B are
both on disk, and the page has already been written to disk as well.
Replay begins from a checkpoint preceding A.
Now, when we get to the record for A, what are we to do? If it were a
full page image, we could just restore it, and everything would be
fine after that. But if we replay the partial page write, we've got
trouble. A will now see the state of the chunk 1 as it existed after
the action protected by B occurred, and will presumably do the wrong
thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-25 12:40:56 | Re: tackling full page writes |
Previous Message | Simon Riggs | 2011-05-25 12:27:47 | Re: Reducing overhead of frequent table locks |