Thread: BUG #7834: Overflow with limited information provided

The following bug has been logged on the website:

Bug reference:      7834
Logged by:          Jackie Zhang
Email address:      jackie.qq.zhang@gmail.com
PostgreSQL version: 9.2.1
Operating system:   Linux
Description:        =


Hi, PostgreSQL, =


I bumped into the error situation which only has the following error log
message available:

"FATAL:  requested shared memory size overflows size_t" =


I tuned down all the memory related options and the system got back
normally. But I really don't know which one caused the problem.

The log message provides quite limited information for users like me to fix
the problem (it's different from typical PostgreSQL's log messages which are
usually super good). =


I wonder whether it's possible to print information like "what is the
limited", "which configuration option is overflowed", etc. These infomation
is of great help to users like me to fix the problem.

Thank you very much!
Jackie

On Tue, Jan 29, 2013 at 2:57 PM,  <jackie.qq.zhang@gmail.com> wrote:

>
> I wonder whether it's possible to print information like "what is the
> limited", "which configuration option is overflowed", etc. These infomation
> is of great help to users like me to fix the problem.
>

I think the error message gives a hint that the limit is the max value
that can be represented by size_t, which would most likely be 2^32 on
a 32-bit machine and 2^64 on a 64 machine. But I understand that it
might be a good idea to print the numeric value based on the known
value of size_t

The other part about what caused the overflow is a bit tricky because
even if the overflow got detected while adding size information for
some GUC, the real culprit might be something else and it will
difficult to find what caused the overflow. It would be a combination
of settings that will lead to this error. I guess you must be running
a 32-bit machine because causing this error on a 64-bit machine will
take some serious over-setting for a number of parameters.

Thanks,
Pavan


--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee