Asynchronous commit | Transaction loss at server crash

Поиск
Список
Период
Сортировка
От Balkrishna Sharma
Тема Asynchronous commit | Transaction loss at server crash
Дата
Msg-id BAY149-w314344813824161D97E691F0E30@phx.gbl
обсуждение исходный текст
Ответы Re: Asynchronous commit | Transaction loss at server crash  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: Asynchronous commit | Transaction loss at server crash  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: Asynchronous commit | Transaction loss at server crash  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-admin
Hello,
Couple of questions:
1. For the 'Asynchronous commit' mode, I know that WAL transactions not flushed to permanent storage will be  lost in event of a server crash. Is it possible to know what were the non-flushed transactions that were lost, in any shape/form/part ? I guess not, but wanted to confirm.

2. If above is true, then for my application 'Asynchronous commit' is not an option. In that case, how is it possible to increase the speed of 'Synchronous Commit' ? Can a SDD rather than HDD make a difference ? Can throwing RAM have an impact ? Is there some test somewhere of how much RAM will help to beef up the write process (for synch commit).

I need to support several hundreds of concurrent update/inserts from an online form with pretty low latency (maybe couple of milliseconds at max). Think of a save to database at every 'tab-out' in an online form.

Thanks,
-Bala



The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: could not truncate directory "pg_subtrans": apparent wraparound
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Clarification Needed: When does autovacuum daemon run?