Re: Posix Shared Mem patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Posix Shared Mem patch
Date
Msg-id 15340.1340751525@sss.pgh.pa.us
Whole thread Raw
In response to Re: Posix Shared Mem patch  ("A.M." <agentm@themactionfaction.com>)
Responses Re: Posix Shared Mem patch
List pgsql-hackers
"A.M." <agentm@themactionfaction.com> writes:
> This can be trivially reproduced if one runs an old (SysV shared memory-based) postgresql alongside a potentially
newerpostgresql 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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Posix Shared Mem patch
Next
From: Nils Goroll
Date:
Subject: experimental: replace s_lock spinlock code with pthread_mutex on linux