search for: max_stack_depth

Hi Thomas, > Could anybody point me in the right direction for setting the kernel > parameter, max_stack_depth, to 10240 for database tuning? > > I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot. > > Thanks for the response, I've been nosing around that file recently but noted the first two lines; #This file sets the resource limits for...

Hi All, Could anybody point me in the right direction for setting the kernel parameter, max_stack_depth, to 10240 for database tuning? I have currently set it by running 'ulimit -s 10240' but this does not survive a reboot. I've Googled plenty and can't find any solution, thanks Michael

On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: > Hi Thomas, > > > > Could anybody point me in the right direction for setting the kernel > > parameter, max_stack_depth, to 10240 for database tuning? > > > > I have currently set it by running 'ulimit -s 10240' but this does not > > survive a reboot. > > > > > > Thanks for the response, I've been nosing around that file recently but > noted the first two lines...

On Aug 14, 2015 08:45, Jason Warr <jason at warr.net> wrote: > > On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: > > Hi Thomas, > > > > > > > Could anybody point me in the right direction for setting the kernel > > > parameter, max_stack_depth, to 10240 for database tuning? > > > > > > I have currently set it by running 'ulimit -s 10240' but this does not > > > survive a reboot. > > > > > > > > > > Thanks for the response, I've been nosing around that file recent...

Hi Jason, On 14/08/15 16:45, Jason Warr wrote: > On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: >> Hi Thomas, >> >> >>> Could anybody point me in the right direction for setting the kernel >>> parameter, max_stack_depth, to 10240 for database tuning? >>> >>> I have currently set it by running 'ulimit -s 10240' but this does not >>> survive a reboot. >>> >>> >> >> Thanks for the response, I've been nosing around that file recently but >> not...

...ael H wrote: > Hi Jason, > > On 14/08/15 16:45, Jason Warr wrote: >> On Fri, 2015-08-14 at 16:31 +0100, Michael H wrote: >>> Hi Thomas, >>> >>> >>>> Could anybody point me in the right direction for setting the kernel >>>> parameter, max_stack_depth, to 10240 for database tuning? >>>> >>>> I have currently set it by running 'ulimit -s 10240' but this does not >>>> survive a reboot. >>>> >>>> >>> >>> Thanks for the response, I've been nosing around that fi...

Hi All, >>>>> Could anybody point me in the right direction for setting the kernel >>>>> parameter, max_stack_depth, to 10240 for database tuning? >>>>> >>>>> I have currently set it by running 'ulimit -s 10240' but this does not >>>>> survive a reboot. >>>>> >>>>> >>>> >>>> Thanks for the response, I'v...

Could anybody point me in the right direction for setting the kernel parameter, max_stack_depth, to 10240 for database tuning? I have currently set it by running 'ulimit -s 10240' but this does not survive a reboot. Look at the file /etc/security/limits.conf For documentation, 'man limits.conf' - Thomas

...pt a value in bytes. That is, you've decreased the stack size to 12KiB, which is why PostgreSQL segfaults immediately. # cat /etc/systemd/system/postgresql.service .include /lib/systemd/system/postgresql.service [Service] LimitSTACK=12582912 # grep stack /var/lib/pgsql/data/postgresql.conf max_stack_depth = 10MB # min 100kB # systemctl daemon-reload # systemctl restart postgresql

On 08/14/2015 07:19 AM, Michael H wrote: > I have currently set it by running 'ulimit -s 10240' but this does not > survive a reboot. It's already been pointed out that you'll need to modify the init script, but just to make clear why that is the case, I thought it should be pointed out that "ulimit" is a bash built-in command. When you run "ulimit -s

On Fri, 14 Aug 2015, Thomas Eriksson wrote: >If it's centos 6 stick 'ulimit -s' in the init script I suggest putting it in the sysconfig file instead, if such exists. /mark

On Aug 15, 2015 13:23, Mark Milhollan <mlm at pixelgate.net> wrote: > > On Fri, 14 Aug 2015, Thomas Eriksson wrote: > > >If it's centos 6 stick 'ulimit -s' in the init script > > I suggest putting it in the sysconfig file instead, if such exists. > > Sure, but how many init scripts provide for adding an extra command via sysconfig files? Most of

Am 15.08.2015 um 23:38 schrieb Thomas Eriksson <thomas.eriksson at slac.stanford.edu>: > > On Aug 15, 2015 13:23, Mark Milhollan <mlm at pixelgate.net> wrote: >> >> On Fri, 14 Aug 2015, Thomas Eriksson wrote: >> >>> If it's centos 6 stick 'ulimit -s' in the init script >> >> I suggest putting it in the sysconfig file

...new kernel > and the new glibc among other things, After the update completed it > knocked my master postgresql database offline. > > > Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... > Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter > "max_stack_depth": 16384 > Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed > 7680kB. > Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth > limit via "ulimit -s" or local equivalent. > Feb 17 13:46:11 db1 pg_ctl: FATAL: configur...

On 02/17/2016 07:08 AM, Michael H wrote: > On 17/02/16 13:01, Johnny Hughes wrote: >> I normally just let the daily announce post to this list show what >> is available for updates, but there is a CVE (CVE-2015-7547) that >> needs a bit more attention which will be on today's announce list >> of updates. >> >> We released a new glibc yesterday for

...ver (yum update -y) which applied a new kernel and the new glibc among other things, After the update completed it knocked my master postgresql database offline. Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter "max_stack_depth": 16384 Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed 7680kB. Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth limit via "ulimit -s" or local equivalent. Feb 17 13:46:11 db1 pg_ctl: FATAL: configuration file "/var/lib...

...things, After the update completed it >>> knocked my master postgresql database offline. >>> >>> >>> Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... >>> Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter >>> "max_stack_depth": 16384 >>> Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed >>> 7680kB. >>> Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth >>> limit via "ulimit -s" or local equivalent. >>> Feb...

...ver (yum update -y) which applied a new kernel and the new glibc among other things, After the update completed it knocked my master postgresql database offline. Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter "max_stack_depth": 16384 Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed 7680kB. Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth limit via "ulimit -s" or local equivalent. Feb 17 13:46:11 db1 pg_ctl: FATAL: configuration file "/var/lib...

...he new glibc among other things, After the update completed it >> knocked my master postgresql database offline. >> >> >> Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... >> Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter >> "max_stack_depth": 16384 >> Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed >> 7680kB. >> Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth >> limit via "ulimit -s" or local equivalent. >> Feb 17 13:46:11 db1 pg_c...

...new kernel > and the new glibc among other things, After the update completed it > knocked my master postgresql database offline. > > > Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... > Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter > "max_stack_depth": 16384 > Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed > 7680kB. > Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth > limit via "ulimit -s" or local equivalent. > Feb 17 13:46:11 db1 pg_ctl: FATAL: configur...