Re: crash-safe visibility map, take five

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: crash-safe visibility map, take five
Дата
Msg-id 1308868853.4284.27.camel@jdavis-ux.asterdata.local
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 2011-06-23 at 18:18 -0400, Robert Haas wrote:
> Lazy VACUUM is the only thing that makes a page all visible.  I don't
> understand the part about snapshots.

Lazy VACUUM is the only thing that _marks_ a page with PD_ALL_VISIBLE. 

After an INSERT to a new page, and after all snapshots are released, the
page becomes all-visible; and thus subject to being marked with
PD_ALL_VISIBLE by lazy vacuum without bumping the LSN. Note that there
is no cleanup action that takes place here, so nothing else will bump
the LSN either.

So, let's say that we hypothetically had persistent snapshots, then
you'd have the following problem:

1. INSERT to a new page, marking it with LSN X
2. WAL flushed to LSN Y (Y > X)
2. Some persistent snapshot (that doesn't see the INSERT) is released,
and generates WAL recording that fact with LSN Z (Z > Y)
3. Lazy VACUUM marks the newly all-visible page with PD_ALL_VISIBLE
4. page is written out because LSN is still X
5. crash

Now, the persistent snapshot is still present because LSN Z never made
it to disk; but the page is marked with PD_ALL_VISIBLE.

Sure, if these hypothetical persistent snapshots were transactional, and
if synchronous_commit is on, then LSN Z would be flushed before step 3;
but that's another set of assumptions. That's why I left it simple and
said that the assumption was "snapshots are released if there's a
crash".

Regards,Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: crash-safe visibility map, take five
Следующее
От: Bruce Momjian
Дата:
Сообщение: pg_upgrade defaulting to port 25432