Re: [GENERAL] huge table occupation after updates

Поиск
Список
Период
Сортировка
От Tom DalPozzo
Тема Re: [GENERAL] huge table occupation after updates
Дата
Msg-id CAK77FCQFrRfgd6mX6f7X6EOz1dSq6dUn7xKiDvMt3vqkeciChg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] huge table occupation after updates  (Francisco Olarte <folarte@peoplecall.com>)
Список pgsql-general
2016-12-10 18:33 GMT+01:00 Francisco Olarte <folarte@peoplecall.com>:
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.

​Hi, perhaps I was not clear. The cache I mentioned is a possible cache in my app, outside postgresql server. 
I answered to Rob's question with more details regarding my app. 

Regards
Pupillo



В списке pgsql-general по дате отправления:

Предыдущее
От: Francisco Olarte
Дата:
Сообщение: Re: [GENERAL] huge table occupation after updates
Следующее
От: Tom DalPozzo
Дата:
Сообщение: Re: [GENERAL] huge table occupation after updates