Re: Auto-tuning work_mem and maintenance_work_mem
От | MauMau |
---|---|
Тема | Re: Auto-tuning work_mem and maintenance_work_mem |
Дата | |
Msg-id | C1DAEA9369E7492C907714DEF815909D@maumau обсуждение исходный текст |
Ответ на | Re: Auto-tuning work_mem and maintenance_work_mem (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Auto-tuning work_mem and maintenance_work_mem
|
Список | pgsql-hackers |
From: "Dimitri Fontaine" <dimitri@2ndQuadrant.fr> > "MauMau" <maumau307@gmail.com> writes: >> Although this is not directly related to memory, could you set >> max_prepared_transactions = max_connections at initdb time? People must > > You really need to have a transaction manager around when issuing > prepared transaction as failing to commit/rollback them will prevent > VACUUM and quickly lead you to an interesting situation. I understand this problem occurs only when the user configured the application server to use distributed transactions, the application server crashed between prepare and commit/rollback, and the user doesn't recover the application server. So only improper operation produces the problem. Just setting max_prepared_transactions to non-zero doesn't cause the problem. Is this correct? Regards MauMau
В списке pgsql-hackers по дате отправления: