Re: crash-safe visibility map, take three
От | Bruce Momjian |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | 201012011536.oB1Fapf16029@momjian.us обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: crash-safe visibility map, take three
|
Список | pgsql-hackers |
Heikki Linnakangas wrote: > On 01.12.2010 15:39, Bruce Momjian wrote: > > Heikki Linnakangas wrote: > >> On 01.12.2010 03:35, Bruce Momjian wrote: > >>> Heikki Linnakangas wrote: > >>>> Let's recap what happens when a VM bit is set: You set the > >>>> PD_ALL_VISIBLE flag on the heap page (assuming it's not set already, it > >>>> usually isn't), and then set the bit in the VM while keeping the heap > >>>> page locked. > >>> > >>> What if we set PD_ALL_VISIBLE on the heap page, wait for a checkpoint to > >>> happen so the heap page is guaranteed to be on disk, then on next read, > >>> if PD_ALL_VISIBLE is set and the VM all-visible bit is not set, set the > >>> VM bit. > >> > >> Hmm, you'd somehow have to know if a checkpoint has happened since the > >> flag was set. And it might be a long wait, which makes it less > > > > Well, doesn't the page LSN tell you that already? > > If we update the LSN when we set the flag, then we have to write the > full-page-image. That's very expensive. If we don't update the LSN, then > the LSN says nothing about when the flag was set. Oh, we don't update the LSN when we set the PD_ALL_VISIBLE flag? OK, please let me think some more. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: