> > If that 1% is random (not time/transaction related), usually you'd rather >have an empty table. > > Why do you think it would be random?
"Heap blocks would be zeroed if they were found to be damaged, following a crash." If you erase full blocks, you have no idea what data you erased; it could be something changed 1 hour ago, 1 month ago, 1 year ago. This is very different from, say, synchronous_commit=off: in that case, "the most recent transactions may be lost if the database should crash". In your case, "some (who knows which???) data is lost". So, to me that sounds like random loss. I don't think that that is different from a corrupted table. You're not deleting rows recently changed; you're deleting everything that is "physically close" to it. > > In other words: is a table that is not consistant with anything else in > > the >db useful? > > That's too big a leap. Why would it suddenly be inconsistent with the > rest of the database? If you delete some data, and you have no idea what data you lost, I don't think you have a consistent db. Unless, of course, your table has no relation with any other table in the db. Of course, all these thoughts are based on the assumption that I know what happens when a block is erased; but my knowledge of postgresql internals is not so good, so I might be *very* wrong -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
