Re: crash-safe visibility map, take three
От | Robert Haas |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | AANLkTim_SX_6UfU+DNkmfmFWuDQnN2Pd51qtP=c9t8xi@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Nov 30, 2010 at 10:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 30.11.2010 06:57, Robert Haas wrote: >>> I can't say I'm totally in love with any of these designs. Anyone >>> else have any ideas, or any opinions about which one is best? > >> Well, the design I've been pondering goes like this: > > Wouldn't it be easier and more robust to just consider VM bit changes to > be part of the WAL-logged actions? That would include updating LSNs on > VM pages and flushing VM pages to disk during checkpoint based on their > LSN values. All of these other schemes seem too complicated and not > provably correct. What WAL-logged actions? The problem case is where a page has no tuples or line pointers that need to be removed, and all we need to do is mark it all-visible. We don't current WAL-log anything in that case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: