Re: BUG #5235: Segmentation fault under high load through JDBC
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: BUG #5235: Segmentation fault under high load through JDBC |
Дата | |
Msg-id | 4B1FB001.9000004@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: BUG #5235: Segmentation fault under high load through JDBC (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #5235: Segmentation fault under high load through JDBC
|
Список | pgsql-bugs |
Andrew Gierth wrote: >>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes: > > Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth, > Robert> by ignoring the existence of another and lower limit imposed > Robert> elsewhere? > > Robert> A little Googling seems to reveal that FreeBSD has a > Robert> parameter called MAXSSIZ (and possibly a variant for 64-bit > Robert> builds). I kind find a lot of people talking about needing > Robert> to raise it (for MySQL, among other things), but I haven't > Robert> been able to determine for certain what the default is. > Robert> Perhaps it is set to a really low value on the OP's system? > > The default is 64MB on i386, 512MB on amd64; that's where the > getrlimit value comes from unless it's been explicitly reduced > somewhere. The kernel MAXSSIZ sets the value of the hard limit for > RLIMIT_STACK for proc0, and everything else inherits that. All > setrlimit calls for RLIMIT_STACK are explicitly clamped to MAXSSIZ, so > there's no way to set that value higher than the kernel limit, and no > way for getrlimit to report a value higher than the real limit. I vaguely recall issues in the past with linking of postgresql (or PLs that require it) against libc_r causing some rather small stack limits being imposed under some circumstances but I don't recall the details any more... Stefan
В списке pgsql-bugs по дате отправления: