"A.M." <age...@themactionfaction.com> writes: > This can be trivially reproduced if one runs an old (SysV shared > memory-based) postgresql alongside a potentially newer postgresql with a > smaller SysV segment. This can occur with applications that bundle postgresql > as part of the app.
I don't believe that that case is a counterexample to what's being proposed (namely, grabbing a minimum-size shmem segment, perhaps 1K). It would only fail if the old postmaster ate up *exactly* SHMMAX worth of shmem, which is not real likely. As a data point, on my Mac laptop with SHMMAX set to 32MB, 9.2 will by default eat up 31624KB, leaving more than a meg available. Sure, that isn't enough to start another old-style postmaster, but it would be plenty of room for one that only wants 1K. Even if you actively try to configure the shmem settings to exactly fill shmmax (which I concede some installation scripts might do), it's going to be hard to do because of the 8K granularity of the main knob, shared_buffers. Moreover, a installation script that did that would soon learn not to, because of the fact that we don't worry too much about changing small details of shared memory consumption in minor releases. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers