Обсуждение: pgsql: Remove misleading hints about reducing the System V request size

Поиск
Список
Период
Сортировка

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

От
Robert Haas
Дата:
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(-)


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

От
Tom Lane
Дата:
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

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

От
Robert Haas
Дата:
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