Skip site navigation (1) Skip section navigation (2)

Re: 8.1beta, SunOS and shmget

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.1beta, SunOS and shmget
Date: 2005-08-29 17:05:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, 29 Aug 2005, Tom Lane wrote:

> "Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
>> So, are the shared memory requirements increased for 8.1 ?
> Yes; mostly from 2PC support I think.  Try reducing
> max_prepared_transactions.  (We might want to debate whether the default
> setting should be smaller than 50 --- it looks to me like that's adding
> over 700K to the default shared memory block size.)

In fact, 0 might be reasonable default. Not many people need 2PC.

Those that do, are arguably better off if they're forced to read the 
manual they might not otherwise read :). The manual can then give some 
good advice, like that the application server becomes a critical 
component with 2PC. And perhaps discuss alternatives application designs 
to avoid 2PC in the first place.

50 is a bad default anyway. If you have max_connections connections that 
simultanously issue a prepare, you need to have 
max_prepared_transactions >= max_connections. You can get away with a 
smaller value most of the time, but if for example another resource 
manager "clogs" for a moment, so that the transaction manager can't finish 
any transactions, you can easily reach the limit.

Assuming the application server doesn't reuse a connection before 2nd 
phase commit (I don't have any hard data on this, but I believe it to be 
the norm. Please correct me if I'm wrong), max_prepared_transactions 
>= max_connections will make the new incoming transactions queue until a 
connection becomes available, while max_prepared_transactions < 
max_connections make the incoming transactions fail at prepare.

- Heikki

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-29 17:28:22
Subject: Re: 8.1beta, SunOS and shmget
Previous:From: Alvaro HerreraDate: 2005-08-29 16:54:30
Subject: Re: 8.1beta, SunOS and shmget

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group