Re: [GENERAL] huge table occupation after updates - Mailing list pgsql-general

From Francisco Olarte
Subject Re: [GENERAL] huge table occupation after updates
Date
Msg-id CA+bJJbzL=KsmaBztA7rFptGcS_OYUCKdqVhszmXtaVZVL3=fKg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] huge table occupation after updates  (Tom DalPozzo <t.dalpozzo@gmail.com>)
Responses Re: [GENERAL] huge table occupation after updates
List pgsql-general
Tom:

On Sat, Dec 10, 2016 at 6:01 PM, Tom DalPozzo <t.dalpozzo@gmail.com> wrote:
> 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.

You are making inconsistent requests. When the server tells your app
it's commited, it has flush the transaction log cache. If your
assertion about is real, you cannot wait for commit, so your
requirements are imposible to satisfy ( of course, you could run with
scissors, but that will loose data without hdd failure ).

Francisco Olarte.


pgsql-general by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: [GENERAL] huge table occupation after updates
Next
From: Tom DalPozzo
Date:
Subject: Re: [GENERAL] huge table occupation after updates