Re: [GENERAL] huge table occupation after updates
От | Francisco Olarte |
---|---|
Тема | Re: [GENERAL] huge table occupation after updates |
Дата | |
Msg-id | CA+bJJbzL=KsmaBztA7rFptGcS_OYUCKdqVhszmXtaVZVL3=fKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] huge table occupation after updates (Tom DalPozzo <t.dalpozzo@gmail.com>) |
Ответы |
Re: [GENERAL] huge table occupation after updates
|
Список | 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 по дате отправления: