Re: [GENERAL] psql 9.3 automatic recovery in progress

2016-10-10 21:43 GMT+02:00 Periko Support : > For the life time in odoo session, can u point me where I can manage that > setting? > > The configuration /etc/openerp-server.conf doesn't have any parameter for > that. > > That must be in a odoo file...? >

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

Scott your script is very clean, I'm testing, thanks. On Mon, Oct 10, 2016 at 3:28 PM, Scott Mead wrote: > > > On Mon, Oct 10, 2016 at 6:15 PM, Tom Lane wrote: >> >> Adrian Klaver writes: >> > On 10/10/2016 12:18 PM, Periko

Re: [GENERAL] LOG: munmap(0x7fff80000000) failed: Invalid argument

Andres Freund writes: > On 2016-10-10 18:21:48 -0400, Tom Lane wrote: >> Chris Richards writes: >>> LOG: munmap(0x7fff8000) failed: Invalid argument >> [ digs in code... ] One theory is that PGSharedMemoryDetach is getting >> called more than once,

Re: [GENERAL] LOG: munmap(0x7fff80000000) failed: Invalid argument

On 2016-10-10 18:21:48 -0400, Tom Lane wrote: > Chris Richards writes: > > Setting up postgresql-9.5 (9.5.4-1.pgdg14.04+2) ... > > Creating new cluster 9.5/main ... > > config /etc/postgresql/9.5/main > > data /var/lib/postgresql/9.5/main > > locale en_US.UTF-8 > > LOG:

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

On Mon, Oct 10, 2016 at 6:15 PM, Tom Lane wrote: > Adrian Klaver writes: > > On 10/10/2016 12:18 PM, Periko Support wrote: > >> I was on vacation, but the issue have the same behavior: > > > Actually no. Before you had: > > > 2016-09-12 09:00:01

Re: [GENERAL] LOG: munmap(0x7fff80000000) failed: Invalid argument

Chris Richards writes: > Setting up postgresql-9.5 (9.5.4-1.pgdg14.04+2) ... > Creating new cluster 9.5/main ... > config /etc/postgresql/9.5/main > data /var/lib/postgresql/9.5/main > locale en_US.UTF-8 > LOG: munmap(0x7fff8000) failed: Invalid argument > [...

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

Adrian Klaver writes: > On 10/10/2016 12:18 PM, Periko Support wrote: >> I was on vacation, but the issue have the same behavior: > Actually no. Before you had: > 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was > terminated by signal 9: Killed > Now you

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

Adrian 2016-10-10 12:00:01 PDT LOG: connection authorized: user=openerp database=template1 2016-10-10 12:00:01 PDT LOG: server process (PID 30394) was terminated by signal 9: Killed 2016-10-10 12:00:01 PDT DETAIL: Failed process was running: SELECT "name", "model", "description", "month" FROM

Re: [GENERAL] psql 9.3 automatic recovery in progress

> On 10 Oct 2016, at 21:43, Periko Support wrote: > > For the life time in odoo session, can u point me where I can manage that > setting? > > The configuration /etc/openerp-server.conf doesn't have any parameter for > that. > > That must be in a odoo file...? >

[GENERAL] LOG: munmap(0x7fff80000000) failed: Invalid argument

Howdy. I have an Ubuntu 14.04 LTS, configured with huge pages (4x1GB, disabled transparent) and a later kernel than what ships with 14.04. root@ff2:~# uname -a Linux ff2 3.16.7-ckt11-061515+ #1 SMP Mon Jun 15 18:47:13 CDT 2015 x86_64 x86_64 x86_64 GNU/Linux It had postgresql-9.3 on it and I

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

On 10/10/2016 12:18 PM, Periko Support wrote: I was on vacation, but the issue have the same behavior: Actually no. Before you had: 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was terminated by signal 9: Killed Now you have: 2016-10-10 07:50:09 PDT WARNING: terminating

Re: [GENERAL] custom average window function failure

On Sun, Oct 9, 2016 at 10:10 PM, Sebastian P. Luque wrote: > On Sun, 09 Oct 2016 16:00:21 -0400, > Tom Lane wrote: > >> "Sebastian P. Luque" writes: >>> Tom Lane wrote: On closer inspection, the error is only in

Re: [GENERAL] psql 9.3 automatic recovery in progress

For the life time in odoo session, can u point me where I can manage that setting? The configuration /etc/openerp-server.conf doesn't have any parameter for that. That must be in a odoo file...? Thanks. On Mon, Oct 10, 2016 at 12:25 PM, Pavel Stehule wrote: > > >

Re: [GENERAL] psql 9.3 automatic recovery in progress

That script was from a vendor called 'allianzgrp.com'. Was their solution. Them I have a lot of work to do here. On Mon, Oct 10, 2016 at 12:32 PM, Alban Hertroys wrote: > >> On 10 Oct 2016, at 21:28, Alban Hertroys wrote: >> >> >>> On 10 Oct 2016, at

Re: [GENERAL] psql 9.3 automatic recovery in progress

> On 10 Oct 2016, at 21:28, Alban Hertroys wrote: > > >> On 10 Oct 2016, at 21:12, Periko Support wrote: >> >>for pid in idle_record: >>try: >> #print "process details",pid >> #os.system("kill -9 %s" %

Re: [GENERAL] psql 9.3 automatic recovery in progress

> On 10 Oct 2016, at 21:12, Periko Support wrote: > > for pid in idle_record: > try: > #print "process details",pid > #os.system("kill -9 %s" % (int(pid[0]), )) > os.kill(int(pid[0]), signal.SIGKILL) > except

Re: [GENERAL] psql 9.3 automatic recovery in progress

2016-10-10 21:12 GMT+02:00 Periko Support : > Andreo u got a good observation here. > > I got a script that run every hour why? > > Odoo got some issues with IDLE connections, if we don't check our current > psql connections after a while the system eat all connections

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

I was on vacation, but the issue have the same behavior: 2016-10-10 07:50:09 PDT WARNING: terminating connection because of crash of another server process 2016-10-10 07:50:09 PDT DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because

Re: [GENERAL] HA Cluster Solution?

I'm trying to get better numbers, is a option in the table. Meanwhile I reading some system performance numbers. Yes odoo is strange sometimes. But a cluster will be good for HA. Thanks. On Mon, Oct 10, 2016 at 11:12 AM, Pavel Stehule wrote: > Hi > > 2016-10-10 17:20

Re: [GENERAL] psql 9.3 automatic recovery in progress

Andreo u got a good observation here. I got a script that run every hour why? Odoo got some issues with IDLE connections, if we don't check our current psql connections after a while the system eat all connections and a lot of them are IDLE and stop answering users, we create a script that runs

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

On 10/10/2016 11:14 AM, Moreno Andreo wrote: Il 10/10/2016 18:24, Periko Support ha scritto: 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was terminated by signal 9: Killed 2016-09-12 10:00:01 PDT LOG: server process (PID 30766) was terminated by signal 9: Killed 2016-09-12

Re: [GENERAL] psql 9.3 automatic recovery in progress

Periko Support writes: > My current server has 82GB memory. You said this was running inside a VM, though --- maybe the VM is resource-constrained? In any case, turning off memory overcommit would be a good idea if you're not concerned about running anything but

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

On Mon, Oct 10, 2016 at 2:14 PM, Moreno Andreo wrote: > > Il 10/10/2016 18:24, Periko Support ha scritto: > >> 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was >> terminated by signal 9: Killed >> > > 2016-09-12 10:00:01 PDT LOG: server process (PID 30766)

Re: [SPAM] [GENERAL] psql 9.3 automatic recovery in progress

Il 10/10/2016 18:24, Periko Support ha scritto: 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was terminated by signal 9: Killed 2016-09-12 10:00:01 PDT LOG: server process (PID 30766) was terminated by signal 9: Killed 2016-09-12 15:00:01 PDT LOG: server process (PID 22030)

Re: [GENERAL] HA Cluster Solution?

Hi 2016-10-10 17:20 GMT+02:00 Periko Support : > I have done some tuning for psql base on odoo, but I want to know if a > cluster can help to get a better performance, this why I ask here in > the community who has experience with clusters. > Appreciate your help

Re: [GENERAL] psql 9.3 automatic recovery in progress

Or add more memory to my server? On Mon, Oct 10, 2016 at 11:05 AM, Periko Support wrote: > My current server has 82GB memory. > > Default settings but the only parameter I had chance is shared_buffers > from 128MB to 6G. > > This server is dedicated to postgresql+odoo.

Re: [GENERAL] psql 9.3 automatic recovery in progress

My current server has 82GB memory. Default settings but the only parameter I had chance is shared_buffers from 128MB to 6G. This server is dedicated to postgresql+odoo. Is the only parameter I can thing can reduce my memory utilization? Thanks Tom. On Mon, Oct 10, 2016 at 10:03 AM, Tom Lane

Re: [GENERAL] psql 9.3 automatic recovery in progress

Periko Support writes: > I got some issues with my DB under ubuntu 14.x. > PSQL 9.3, odoo 7.x. > 2016-09-12 09:00:01 PDT LOG: server process (PID 23958) was > terminated by signal 9: Killed Usually, SIGKILLs coming out of nowhere indicate that the Linux OOM killer

Re: [GENERAL] psql 9.3 automatic recovery in progress

I want to add my server load normally, please see attachment, thanks. ​ On Mon, Oct 10, 2016 at 9:24 AM, Periko Support wrote: > I got some issues with my DB under ubuntu 14.x. > PSQL 9.3, odoo 7.x. > > This machine is under KVM with centos 6.x > > It has a Raid1

[GENERAL] psql 9.3 automatic recovery in progress

I got some issues with my DB under ubuntu 14.x. PSQL 9.3, odoo 7.x. This machine is under KVM with centos 6.x It has a Raid1 with ssd drives only for this vm. I detect some unexpected shutdows, see this lines: 2016-09-12 08:59:25 PDT ERROR: missing FROM-clause entry for table "rp" at

Re: [GENERAL] HA Cluster Solution?

I have done some tuning for psql base on odoo, but I want to know if a cluster can help to get a better performance, this why I ask here in the community who has experience with clusters. Appreciate your help Pavel. On Sun, Oct 9, 2016 at 9:29 PM, Pavel Stehule wrote: >

Re: [GENERAL] Transactional-DDL DROP/CREATE TABLE

On Thu, Oct 6, 2016 at 4:21 AM, Geoff Winkless wrote: > Hi > > I have code that does (inside a single transaction) > > DROP TABLE IF EXISTS mytable; CREATE TABLE mytable > > Occasionally this produces > > ERROR: duplicate key value violates unique constraint >

Re: [GENERAL] How pg_dump works

Il 10/10/2016 14:16, haman...@t-online.de ha scritto: Hi all, I need to pg_dump a database to another server. The particularity is that the database is bigger than remaining space on disk. Obviously, this is not a problem because i'm dumping to another host, but I need to know if the

Re: [GENERAL] How pg_dump works

Il 10/10/2016 14:16, Achilleas Mantzios ha scritto: On 10/10/2016 14:50, Moreno Andreo wrote: Hi all, I need to pg_dump a database to another server. The particularity is that the database is bigger than remaining space on disk. Obviously, this is not a problem because i'm dumping to

Re: [GENERAL] How pg_dump works

>> Hi all, >> I need to pg_dump a database to another server. >> The particularity is that the database is bigger than remaining space on >> disk. Obviously, this is not a problem because i'm dumping to another >> host, but I need to know if the procedure streams data to remote host or >>

Re: [GENERAL] How pg_dump works

On 10/10/2016 14:50, Moreno Andreo wrote: Hi all, I need to pg_dump a database to another server. The particularity is that the database is bigger than remaining space on disk. Obviously, this is not a problem because i'm dumping to another host, but I need to know if the procedure streams

[GENERAL] How pg_dump works

Hi all, I need to pg_dump a database to another server. The particularity is that the database is bigger than remaining space on disk. Obviously, this is not a problem because i'm dumping to another host, but I need to know if the procedure streams data to remote host or the data itself is

Re: [GENERAL] Transactional-DDL DROP/CREATE TABLE

On 6 October 2016 at 18:33, Tom Lane wrote: > I'm a bit confused about exactly what the context is here. AFAICS, > the fragment you quoted should work as you expect, as long as the > table always exists beforehand. Then, the DROPs serialize the > transactions' access to the

Re: [GENERAL] Transactional-DDL DROP/CREATE TABLE

On 6 October 2016 at 18:25, Adrian Klaver wrote: > I do not see sarcasm, I see someone trying to work through what is a complex > scenario. When someone talks about things "magically working as you think it should" I see sarcasm. Perhaps I misread, in which case I