Re: huge table occupation after updates

2016-12-10 16:36 GMT+01:00 Rob Sargent <robjsargent(at)gmail(dot)com>:

>
> > On Dec 10, 2016, at 7:27 AM, Tom DalPozzo <t(dot)dalpozzo(at)gmail(dot)com> wrote:
> >
> > Hi,
> > I'd like to do that! But my DB must be crash proof! Very high
> reliability is a must.
> > I also use sycn replication.
> > Regards
> > Pupillo
> >
> >
> >
> >
> > Are each of the updates visible to a user or read/analyzed by another
> activity? If not you can do most of the update in memory and flush a
> snapshot periodically to the database.
> >
> >
>
> This list discourages top posting. You’re asked to place your reply at the
> bottom
>
> You haven’t laid out you’re application architecture (how many clients,
> who is reading who is writing, etc). Caching doesn’t mean your database is
> any less crash proof. At that rate of activity, depending on architecture,
> you could lose updates in all sorts of crash scenarios.

​As for crash proof, I meant that once my client app is told that her
update request was committed, it mustn't get lost (hdd failure apart of
course). And I can't wait to flush the cache before telling to the app
:"committed".
​I can replicate also the cache on the standby PC of course. ​
Regards
Pupillo

​