Hi,
On 08/09/2010 05:41 PM, Tom Lane wrote:
... and on some platforms, it'll be flat out impossible. We looked at
this years ago and concluded that changing the size of the shmem segment
after postmaster start was impractical from a portability standpoint.
I have not seen anything to change that conclusion.
I haven't tried, but I tend to believe that's true.
However, I'd like to get back to the original intent of the posted
patch. Which is about dynamically allocating memory *within a fixed size
pool*.
That's something SRLU or shared_buffers do to some extent, but with lots
of limitations. And without the ability to move free memory between
sub-systems (i.e. between different SLRU buffers).
You meant "I don't think", right? I agree. The only way threads would
simplify this is if we went over to a mysql-style model where there was
only one process, period, and all backends were threads inside that.
No shared memory as such, at all.
That's how the threaded model normally is used, yes. And with that
model, allocation of shared memory is very easy. It has none of the
pre-allocation requirements we are currently facing.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
