search for: pg_ctl

..., I updated my server (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...

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

...plied 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 >>>...

...rything is protected. Wow, so, I updated my server (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...

...hard stack 12288 in an attempt to set the stack depth to 12MB so that I can configure postgresql max_stack_depth = 10MB. I rebooted, ulimit -s shows 12288. When I restart my service (#It does not affect resource limits of the system services.) becomes apparent. Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: invalid value for parameter "max_stack_depth": 10240 Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: "max_stack_depth" must not exceed 7680kB. Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16...

...rything is protected. Wow, so, I updated my server (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...

...(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 "ulim...

...to 12MB so that I can configure >> postgresql max_stack_depth = 10MB. >> >> I rebooted, ulimit -s shows 12288. >> >> When I restart my service (#It does not affect resource limits of the >> system services.) becomes apparent. >> >> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: >> invalid value for parameter "max_stack_depth": 10240 >> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: >> "max_stack_depth" must not exceed 7680kB. >> Aug 14 16:22:17 d...

..., I updated my server (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...

...>>> postgresql max_stack_depth = 10MB. >>> >>> I rebooted, ulimit -s shows 12288. >>> >>> When I restart my service (#It does not affect resource limits of the >>> system services.) becomes apparent. >>> >>> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: >>> invalid value for parameter "max_stack_depth": 10240 >>> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: >>> "max_stack_depth" must not exceed 7680kB. >>> A...

...mpt to set the stack depth to 12MB so that I can configure > postgresql max_stack_depth = 10MB. > > I rebooted, ulimit -s shows 12288. > > When I restart my service (#It does not affect resource limits of the > system services.) becomes apparent. > > Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: > invalid value for parameter "max_stack_depth": 10240 > Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: > "max_stack_depth" must not exceed 7680kB. > Aug 14 16:22:17 db1 pg_ctl[3177]...

...I can configure > > postgresql max_stack_depth = 10MB. > > > > I rebooted, ulimit -s shows 12288. > > > > When I restart my service (#It does not affect resource limits of the > > system services.) becomes apparent. > > > > Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: > > invalid value for parameter "max_stack_depth": 10240 > > Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >DETAIL: > >?? "max_stack_depth" must not exceed 7680kB. > > Aug 14 16:...

...stack_depth = 10MB. >>>> >>>> I rebooted, ulimit -s shows 12288. >>>> >>>> When I restart my service (#It does not affect resource limits of the >>>> system services.) becomes apparent. >>>> >>>> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >LOG: >>>> invalid value for parameter "max_stack_depth": 10240 >>>> Aug 14 16:22:17 db1 pg_ctl[3177]: < 2015-08-14 16:22:17.839 BST >>>> >DETAIL: >>>> "max_stack_depth" must not...

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

...erver (postgres) before tests are run and stop it afterwards. For this, I have created a little wrapper around rake: $ cat run-rake #! /bin/sh DB=`pwd`/db/pgdata # init database cluster if it does not exist yet [ -d $DB ] || initdb -D$DB # start the database server pg_ctl -D$DB -o "-h '''' -k $DB" -l postgreslog start # wait for it to accept connections sleep 1 # run rake with original arguments rake "$*" # we''re done, stop database server again pg_ctl -D$DB -o "-h '''' -k...

...ay with systemd, but it doesn't happen because it quickly starts to be very complex and it's a lot of work to do it for a complete distribution. It just doesn't happen - or at least did not happen in all the years since its introduction. In this example, PG gets just started with "pg_ctl start" and that's it. Regards, Simon

Hello Everybody, I am trying to configure Asterisk to listen into a database which is created in PostgreSQL. Whenever asterisk starts up, it is unable to connect to the pg database and gives the following error: [cdr_pgsql.so] => (PostgreSQL CDR Backend) == Parsing '/etc/asterisk/cdr_pgsql.conf': Found Jun 24 21:20:53 DEBUG[1074494336]: cdr_pgsql.c:284 my_load_module: cdr_pgsql:

When I run the rake db:migrate command, I get this: C:\testror\depot>rake db:migrate --trace (in C:/testror/depot) ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate rake aborted! 182: Le systÞme d''exploitation ne peut pas exÚcuter %1. - c:/ruby/ lib/ruby/gem

...ules/ovirt/manifests/postgres.pp +++ b/installer/modules/ovirt/manifests/postgres.pp @@ -38,10 +38,15 @@ class postgres::bundled{ require => Package[postgresql-server] } + single_exec {"start_pgsql": + command => "/bin/su - postgres -c '/usr/bin/pg_ctl start -w -D /var/lib/pgsql/data'", + require => Single_exec["initialize_db"] + } + service {"postgresql" : ensure => running, enable => true, - require => Single_exec[initialize_db] + require => [Single_exec[initiali...

Hi List, I am trying to understand what After= means in a unit file. Does it mean after the specified target is up and operational or only that the target has been started? I have something that needs postgres but postgres needs to be operational not just started. Sometimes it can take a bit for postgres to become operational. Thanks, Steve