From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Dimitri Fontaine" <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org>, "Josh Berkus" <josh(at)agliodbs(dot)com> |
Subject: | Re: Auto-tuning work_mem and maintenance_work_mem |
Date: | 2013-10-12 00:26:22 |
Message-ID: | C1DAEA9369E7492C907714DEF815909D@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Dimitri Fontaine" <dimitri(at)2ndQuadrant(dot)fr>
> "MauMau" <maumau307(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-10-12 05:30:35 | Re: Triggers on foreign tables |
Previous Message | MauMau | 2013-10-12 00:14:36 | Re: Auto-tuning work_mem and maintenance_work_mem |