From: Robert Haas [mailto:robertmh...@gmail.com] Sent: Thursday, August 09, 2012 11:18 PM On Thu, Aug 9, 2012 at 12:43 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >>> So suppose that the following sequence of events occurs: >> >>> 1. Tuple A on page 1 is updated. The new version, tuple B, is placed on >>> page 2. >>> 2. The table is vacuumed, removing tuple A. >>> 3. Page 1 is written durably to disk. >>> 4. Crash. >> >>> If reconstructing tuple B requires possession of tuple A, it seems >>> that we are now screwed. > >> Not with full_page_writes=on, as crash recovery will restore the old page >> contents. But you're right, with full_page_writes=off you are screwed.
> 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. > and I also > agree with Simon's objection upthread: the current design minimizes > the chances of corruption propagating from block to block. Even if > the proposed design is bullet-proof as of this moment (at least with > full_page_writes=on) it seems very possible that it could get > accidentally broken by future code changes, leading to hard-to-find > data corruption bugs. It might also complicate other things that we > will want to do down the line, like parallelizing recovery. I can see the problem incase we remove full-page-writes concept and replace with some other equivalent concept which doesn't have current flexibility. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
