Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Posix Shared Mem patch
Date: 2012-06-26 22:58:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"A.M." <agentm(at)themactionfaction(dot)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

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Nils GorollDate: 2012-06-26 22:58:47
Subject: experimental: replace s_lock spinlock code with pthread_mutex on linux
Previous:From: Kevin GrittnerDate: 2012-06-26 22:25:40
Subject: Re: Posix Shared Mem patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group