From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Date: | 2012-08-30 17:53:29 |
Message-ID: | CA+TgmoaJBr8VFkpb5RiebtHTqMpObu-NVyObhoPE+qohwgwcMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 10, 2012 at 1:25 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> I think the property that recovery only needs to worry about each
>> block individually is one that we want to preserve. Supporting this
>> optimizating only when full_page_writes=off seems ugly,
>
> I think recovery needs to worry about multiple blocks as well in some cases.
> Please see below case and correct me if I am wrong.
> I think currently also there can be problems in case of full_page_writes=off
> for crash recovery.
> 1. Tuple A on page 1 is updated. The new version, tuple B, is placed on
> page 2.
> 2. Page 1 is Partially written to disk.
> 3. During recovery, it can so appear that there is no need to update XMAX
> and other related things in Old tuple
> as LSN is greater than WAL lsn.
> 4. Now also there can be other problems related to tuple visibility.
Well, you're only supposed to turn full_page_writes=off if partial
page writes are impossible on your system. If you turn off
full_page_writes on a system where partial page writes are impossible,
then you've intentionally broken crash recovery, and you get to keep
both pieces.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-08-30 18:18:30 | Re: patch: shared session variables |
Previous Message | Robert Haas | 2012-08-30 17:50:50 | Re: patch: shared session variables |