2011/4/25 Christopher Browne <cbbrowne@gmail.com>:
> On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh <jesper@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.
That is true but the application performance has already to cope with
a server crash/restart. Many things you can add to make the restart
(for the application) more 'smooth' is good.
>
> 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
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support