Re: crash-safe visibility map, take three
От | Heikki Linnakangas |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | 4CF67B5C.9030003@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: crash-safe visibility map, take three
|
Список | pgsql-hackers |
On 01.12.2010 18:40, Tom Lane wrote: > Robert Haas<robertmhaas@gmail.com> writes: >> As far as I can tell, there are basically two viable solutions on the >> table here. > >> 1. Every time we observe a page as all-visible, (a) set the >> PD_ALL_VISIBLE bit on the page, without bumping the LSN; (b) set the >> bit in the visibility map page, bumping the LSN as usual, and (c) emit >> a WAL record indicating the relation and block number. On redo of >> this record, set both the page-level bit and the visibility map bit. >> The heap page may hit the disk before the WAL record, but that's OK; > > Um, no it isn't. Suppose the heap page gets to disk but we crash before > the WAL record does. Now we have a persistent state where the heap page > is marked PD_ALL_VISIBLE but the corresponding VM bit is not set. The > VM bit will never become set, either, because operations on the heap > page will see PD_ALL_VISIBLE and assume it already is set. This state > of affairs might be acceptable from a correctness standpoint, but not > from a performance standpoint. The next vacuum will fix it. We already handle that. It's no different from the situation where neither change makes it to the disk. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: