Displaying 20 results from an estimated 21 matches for "pg_ctl".
Did you mean:
pg_call
2016 Feb 17
2
New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547
..., 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...
2016 Feb 17
4
New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547
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
2016 Feb 17
2
New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547
...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
>>>...
2016 Feb 17
1
New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547
...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...
2015 Aug 14
4
persistent change of max_stack_depth
...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...
2016 Feb 17
0
Kernel parameters ignored -
...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...
2016 Feb 17
0
New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547
...(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...
2015 Aug 17
2
persistent change of max_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 d...
2016 Feb 17
2
Kernel parameters ignored -
..., 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...
2015 Aug 17
0
persistent change of max_stack_depth
...>>> 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...
2015 Aug 14
0
persistent change of max_stack_depth
...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]...
2015 Aug 14
2
persistent change of max_stack_depth
...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:...
2015 Aug 17
2
persistent change of max_stack_depth
...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...
2015 Aug 14
4
persistent change of max_stack_depth
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
2010 Feb 04
0
How to start/stop database from rake?
...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...
2019 Jan 09
3
systemd
...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
2004 Jun 24
4
Asterisk with PostgreSQL
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:
2008 Jun 03
11
rake db:migrate not working
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
2009 Jun 19
0
[PATCH server] make postgres wait for starting to complete before creating databases
...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...
2019 Jan 09
3
systemd
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