On Mon, 2010-08-09 at 11:41 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > So imagine that thread-or-process A allocates allocates a new chunk of > > memory and then writes a pointer to the new chunk in a previously > > allocated section of memory. Thread-or-process B then follows the > > pointer. In a threaded model, this is guaranteed to be safe. In a > > process model, it's not: A might have enlarged the shared memory > > mapping while B has not yet done so. So I think in our model any sort > > of change to the shared memory segment is going to require extremely > > careful gymnastics, and be pretty expensive. > > ... 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.
As caches get larger, downtime gets longer. Downtime of more than a few minutes per year is enough to blow claims of high availability. At some point, this project will need to face this particular hurdle. We may need to balance utility for the majority against portability for the minority. We should be laying out an architectural roadmap, not just saying no. We can make multi-year plans if we wish to. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
