From: "Bruce Momjian" <>
On Thu, Oct 10, 2013 at 11:01:52PM +0900, MauMau wrote:
Although this is not directly related to memory, could you set
max_prepared_transactions = max_connections at initdb time?  People
must feel frustrated when they can't run applications on a Java or
.NET application server and notice that they have to set
max_prepared_transactions and restart PostgreSQL.  This is far from

I think the problem is that many users don't need prepared transactions
and therefore don't want the overhead.  Is that still accurate?

I'm not sure if many use XA features, but I saw the questions and answer a few times, IIRC. In the trouble situation, PostgreSQL outputs an intuitive message like "increase max_prepared_transactions", so many users might possibly have been able to change the setting and solve the problem themselves without asking for help, feeling stress like "Why do I have to set this?" For example, max_prepared_transactions is called "hideous creature" in the following page:

According to the below page, the amount of memory consumed for this is "(770 + 270 * max_locks_per_transaction) * max_prepared_transactions". With the default setting of maxconnections=100 and max_locks_per_transaction=64, this is only 180KB. So the overhead is negligible.

If the goal is to make PostgreSQL more friendly and run smoothly without frustration from the start and not perfect tuning, I think max_prepared_transactions=max_connections is an easy and good item. If the goal is limited to auto-tuning memory sizes, this improvement can be treated separately.


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to