On 27.12.2011 23:23, Merlin Moncure wrote: > On Tue, Dec 27, 2011 at 4:07 PM, Tomas Vondra <tv@xxxxxxxx> wrote: >> That's not likely. The corruption is usually the cause, when it hits >> varlena header - that's where the length info is stored. In that case >> PostgreSQL suddenly thinks the varlena field has a negative value (and >> malloc accepts unsigned integers). > > If the problem truly went away, one likely possibility is that the bad > tuple was simply deleted -- occasionally the corruption is limited to > a tuple or two but doesn't spill over into the page itself -- in such > situations some judicious deletion of rows can get you to a point > where you can pull off a dump. Or maybe the record is not read for some other reason ... maybe the table is accessed in a different way and the corrupted column is not checked. Or maybe it does not match the WHERE condition or something. I've seen cases where the table was accessed sequentially and it was failing (as the column was checked because of the WHERE condition), and then it switched to index scan and it did not fail anymore (because it was not necessary to check the column anymore). Tomas -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
