"Sergey E. Koposov" <math@sai.msu.ru> writes:
> Yes, the decreasing of max_prepared_transaction helped (after some
> testing, I've found that the max_prepared_transactions=3
> max_connections=10 shared_buffers=20 was well enough to fit 1mb of
> shared memory)
20 buffers ... ugh. Obviously we are on the hairy edge of no longer
functioning at all in 1MB shared memory. I'm not sure there is a whole
lot we can do about this, but it's a tad irritating that clog, subtrans,
and multixact are eating the equivalent of about 16 buffers
(nonconfigurable) while the main buffer pool is so badly starved.
It'd be better to reduce their allocations.
How many people still care about small-shmmax systems? Is it worth
flailing around about this, when there are things on the TODO list
(like moving LISTEN/NOTIFY signaling into memory) that will certainly
push our usage irretrievably past 1MB?
One thing I think we should do, though, is teach initdb to modify
max_prepared_transactions along with the other principal knobs.
I believe that the original intention of the default value of 50
was "half of max_connections", and so I'd be inclined to just make
initdb silently set max_prepared_transactions to half of whatever
it's setting max_connections to. As is, 2PC is eating a lot more
than its fair share of resources --- I've noticed for instance on
OS X, with 4MB shmmax by default, that initdb is currently defaulting
to just 200 buffers, which is bad.
regards, tom lane