Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

Поиск
Список
Период
Сортировка
От MauMau
Тема Re: Truncation failure in autovacuum results in data corruption (duplicate keys)
Дата
Msg-id DD016491B9A548D89EE27CB38B94DB7C@tunaPC
обсуждение исходный текст
Ответ на Re: Truncation failure in autovacuum results in data corruption (duplicate keys)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Truncation failure in autovacuum results in data corruption (duplicate keys)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
From: Tom Lane
[ re-reads thread... ]  The extra assumption you need in order to have
trouble is that the blocks in question are dirty in shared buffers and
have never been written to disk since their rows were deleted.  Then
the situation is that the page image on disk shows the rows as live,
while the up-to-date page image in memory correctly shows them as
dead.
Relation truncation throws away the page image in memory without ever
writing it to disk.  Then, if the subsequent file truncate step fails,
we have a problem, because anyone who goes looking for that page will
fetch it afresh from disk and see the tuples as live.


Thank you so much, I got it!  And I'm always impressed at how quick
and concise you are, while you are busy addressing multiple issues and
answering user questions.  Maybe I wouldn't be surprised to hear that
there are multiple clones of Tom Lane.

I'd like to continue to think of a solution and create a patch, based
on the severity and how the customer will respond to our answer.  I
have a feeling that we have to say it's a bit serious, since it
requires recovery from a base backup, not just rebuilding indexes.
The patch development may be after PGCon.

Regards
MauMau





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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Proposal: Adding json logging
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Truncation failure in autovacuum results in data corruption (duplicate keys)