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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2005-08-29 17:28:22|
|Subject: Re: 8.1beta, SunOS and shmget |
|Previous:||From: Alvaro Herrera||Date: 2005-08-29 16:54:30|
|Subject: Re: 8.1beta, SunOS and shmget|