Thread: pgsql: Remove misleading hints about reducing the System V request size

pgsql: Remove misleading hints about reducing the System V request size

From
Robert Haas
Date:
Remove misleading hints about reducing the System V request size.

Since the request size will now be ~48 bytes regardless of how
shared_buffers et. al. are set, much of this advice is no longer
relevant.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/6a77bff086b9bba94ab6cd6229a74f44d3ec266d

Modified Files
--------------
src/backend/port/sysv_shmem.c |   32 +++++++++-----------------------
1 files changed, 9 insertions(+), 23 deletions(-)


Robert Haas <rhaas@postgresql.org> writes:
> Remove misleading hints about reducing the System V request size.

Removing the hints may be a good idea, but removing the request-size
report seems like a very bad idea; especially now that the problem
could easily be with SHMMIN not SHMMAX.

Also, shouldn't these messages now print sysvsize not the original size?

            regards, tom lane

On Tue, Jul 3, 2012 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <rhaas@postgresql.org> writes:
>> Remove misleading hints about reducing the System V request size.
>
> Removing the hints may be a good idea, but removing the request-size
> report seems like a very bad idea; especially now that the problem
> could easily be with SHMMIN not SHMMAX.
>
> Also, shouldn't these messages now print sysvsize not the original size?

Well, it isn't really gone:

         errdetail("Failed system call was shmget(key=%lu, size=%lu, 0%o).",
                    (unsigned long) memKey, (unsigned long) size,
                    IPC_CREAT | IPC_EXCL | IPCProtection),

But if you want to work that back into the text somehow, I'm OK with
that.  We just need some appropriate wording.  I think that failures
are going to be rare enough here that it's not worth expending a lot
of effort to improve this, especially given that we don't really have
any basis for speculating on what the common failure modes are likely
to be; and splicing it into the remaining portion of the messages
seemed awkward.  I have no desire to stand in the way of better ideas,
though, so suggest away...

> Also, shouldn't these messages now print sysvsize not the original size?

InternalIpcMemoryCreate() only gets the sysvsize.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company