On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh <jes...@krogh.cc> wrote: > On 2011-04-25 20:00, Leonardo Francalanci wrote: >>> The amount of data loss on a big table will be <1% of the data >>> loss caused by truncating the whole table. >> >> If that 1% is random (not time/transaction related), usually you'd >> rather have an empty table. In other words: is a table that is not >> consistant with anything else in the db useful? >> > Depends on the application, if it serves for pure caching then it is fully > acceptable and way > better than dropping everything.
Whoah... When cacheing, the application already needs to be able to cope with the case where there's nothing in the cache. This means that if the cache gets truncated, it's reasonable to expect that the application won't get deranged - it already needs to cope with the case where data's not there and needs to get constructed. In contrast, if *wrong* data is in the cache, that could very well lead to wrong behavior on the part of the application. And there may not be any mechanism aside from cache truncation that will rectify that. It seems to me that it's a lot riskier to try to preserve contents of such tables than it is to truncate them. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers