Re: [WIP] Performance Improvement by reducing WAL for Update Operation
От | Robert Haas |
---|---|
Тема | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | CA+TgmoaJBr8VFkpb5RiebtHTqMpObu-NVyObhoPE+qohwgwcMA@mail.gmail.com обсуждение исходный текст |
Ответ на | [WIP] Performance Improvement by reducing WAL for Update Operation (Amit kapila <amit.kapila@huawei.com>) |
Ответы |
Re: [WIP] Performance Improvement by reducing WAL for Update Operation
|
Список | pgsql-hackers |
On Fri, Aug 10, 2012 at 1:25 AM, Amit Kapila <amit.kapila@huawei.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
В списке pgsql-hackers по дате отправления: