Robert Haas <robertmh...@gmail.com> writes: > On Mon, Aug 9, 2010 at 11:41 AM, Tom Lane <t...@sss.pgh.pa.us> 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 done extensive research into this, but I did take a look at > it briefly. It looked to me like the style of shared memory we're > using now (I guess it's System V) has no way to resize a shared memory > segment at all, and certainly no way that's portable. However it also > looked as though POSIX shm (shm_open, etc.) can be resized using > ftruncate(). Whether this is portable to all the platforms we run on, > or whether the behavior of ftruncate() in combination with shm_open() > is in the standard, I'm not sure. It's not portable. That's exactly what we were looking into back when. > I believe I went back and reread > the old threads on this topic and it seems like the sticking point as > far as POSIX shm goes it that it lacks a readable equivalent of > shm_nattch. Yeah, that was another little problem. In principle though we only need one SysV-style shmem segment to get the required interlock, and there could be add-on shmem segments using POSIX or other APIs. But that doesn't get you out from under the portability issue or the memory space management issue (it's unlikely you can enlarge a segment without remapping it). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers