Re: Logical to physical page mapping
От | Tom Lane |
---|---|
Тема | Re: Logical to physical page mapping |
Дата | |
Msg-id | 18433.1351345385@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Logical to physical page mapping (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Logical to physical page mapping
|
Список | pgsql-hackers |
Jan Wieck <JanWieck@Yahoo.com> writes: > The reason why we need full_page_writes is that we need to guard against > torn pages or partial writes. So what if smgr would manage a mapping > between logical page numbers and their physical location in the relation? > At the moment where we today require a full page write into WAL, we > would mark the buffer as "needs relocation". The smgr would then write > this page into another physical location whenever it is time to write it > (via the background writer, hopefully). After that page is flushed, it > would update the page location pointer, or whatever we want to call it. > A thus free'd physical page location can be reused, once the location > pointer has been flushed to disk. This is a critical ordering of writes. > First the page at the new location, second the pointer to the current > location. Doing so would make write(2) appear atomic to us, which is > exactly what we need for crash recovery. I think you're just moving the atomic-write problem from the data pages to wherever you keep these pointers. regards, tom lane
В списке pgsql-hackers по дате отправления: