Re: Auto-tuning work_mem and maintenance_work_mem - Mailing list pgsql-hackers

From MauMau
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id C1DAEA9369E7492C907714DEF815909D@maumau
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Auto-tuning work_mem and maintenance_work_mem  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List 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 by date:

Previous
From: "MauMau"
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Next
From: Kohei KaiGai
Date:
Subject: Re: Triggers on foreign tables