Re: Truncation failure in autovacuum results in data corruption (duplicate keys) - Mailing list pgsql-hackers

From MauMau
Subject Re: Truncation failure in autovacuum results in data corruption (duplicate keys)
Date
Msg-id DD016491B9A548D89EE27CB38B94DB7C@tunaPC
Whole thread Raw
In response to Re: Truncation failure in autovacuum results in data corruption (duplicate keys)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Truncation failure in autovacuum results in data corruption (duplicate keys)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Proposal: Adding json logging
Next
From: Tom Lane
Date:
Subject: Re: Truncation failure in autovacuum results in data corruption (duplicate keys)