Re: Service pgpool

2018-06-09 Thread Bo Peng
Hi, > Jun 08 04:40:17 asa-pgpool02 pgpool-II-10[30787]: Starting pgpool-II-10 > service: pgpool is already running with pid 4285 [FAILED] It seemed like Pgpool-II is already started. Did you start Pgpool-II twice? Also may I ask some questions? - How did you install Pgpool-II, using source

Re: Fwd: compressed bits in sql table

2018-06-09 Thread Adrian Klaver
On 06/09/2018 03:43 PM, SANDEEP GOURNENI wrote: Postgres version is 10.4 field type is char(32).basically its a fee bit field. Can you explain what you mean by 'fee bit'? Also not sure why you need to deal with compressed bits, cannot you not just pull or push a string from/into the field?

Re: Fwd: compressed bits in sql table

2018-06-09 Thread SANDEEP GOURNENI
Postgres version is 10.4 field type is char(32).basically its a fee bit field. it is related to my application. thanks, Sandeep On Sun, Jun 10, 2018 at 4:04 AM Adrian Klaver wrote: > On 06/09/2018 02:40 PM, SANDEEP GOURNENI wrote: > > > > Hi all, > > > > How can we read compressed bits in

Re: Fwd: compressed bits in sql table

2018-06-09 Thread Adrian Klaver
On 06/09/2018 02:40 PM, SANDEEP GOURNENI wrote: Hi all, How can we read compressed bits in postgres.In one of my table field  i have compressed bits.how to read and write them in postgres using cobol program. You are going to need to be more specific: 1) What version of Postgres? 2) What

Fwd: compressed bits in sql table

2018-06-09 Thread SANDEEP GOURNENI
Hi all, How can we read compressed bits in postgres.In one of my table field i have compressed bits.how to read and write them in postgres using cobol program. Thanks, Sandeep

Re: pg_upgrade and wraparound

2018-06-09 Thread Tom Lane
Adrian Klaver writes: > On 06/09/2018 03:46 AM, Alexander Shutyaev wrote: >> The upgrade operation failed after several hours with the following error: >> database is not accepting commands to avoid wraparound data loss in >> database with OID 0 > Do you know which database has an OID of 0?

Re: Slow planning time for simple query

2018-06-09 Thread Tom Lane
Maksim Milyutin writes: > On hot standby I faced with the similar problem. > ... > is planned 4.940 ms on master and *254.741* ms on standby. Presumably the problem is that the standby isn't authorized to change the btree index's "entry is dead" bits, so it's unable to prune index entries

Re: pg_upgrade and wraparound

2018-06-09 Thread Adrian Klaver
On 06/09/2018 03:46 AM, Alexander Shutyaev wrote: Hello! I've been trying to upgrade a postgresql cluster from 9.6 to 10. I've executed the pg_upgrade with the following options:  /usr/lib/postgresql/10/bin/pg_upgrade -b /usr/lib/postgresql/9.6/bin/ -B /usr/lib/postgresql/10/bin/ -d

Re: Slow planning time for simple query

2018-06-09 Thread Maksim Milyutin
On 09.06.2018 21:49, Maksim Milyutin wrote: On hot standby I faced with the similar problem. Sorry, the problem in question is described here https://www.postgresql.org/message-id/22136.1528312205%40sss.pgh.pa.us -- Regards, Maksim Milyutin

Re: Slow planning time for simple query

2018-06-09 Thread Maksim Milyutin
On hot standby I faced with the similar problem. The following simple query: SELECT array_to_json(array_agg(t)) from (     select *     from main.message m     join main.message_instance mi on m.message_id = mi.message_id     join main.channel_type ct on

Re: Performance problem postgresql 9.5

2018-06-09 Thread Miguel Angel Sanchez Sandoval
Guys, indeed I had an intruder, with the recent migration I installed a remote mirror that had a vulnerability. Thank you very much for your fast response. My best regards Libre de virus.

Re: (2^63 - 1)::bigint => out of range? (because of the double precision)

2018-06-09 Thread Alexey Dokuchaev
On Sat, Jun 09, 2018 at 07:20:17AM -0700, Adrian Klaver wrote: > On 06/09/2018 05:24 AM, Alexey Dokuchaev wrote: > >OK, but what about highly volatile tables for come-and-go type of things? > >Think of a session pool, or task queue. I want to use NO CYCLE for this > >kind of tables as it would

Re: (2^63 - 1)::bigint => out of range? (because of the double precision)

2018-06-09 Thread Adrian Klaver
On 06/09/2018 05:24 AM, Alexey Dokuchaev wrote: On Fri, Jun 08, 2018 at 10:30:45AM -0700, Adrian Klaver wrote: My guess is because sequences are often used to provide numbers for a PRIMARY KEY and NO CYCLE is a heads up for key duplication before the PK code kicks in. OK, but what about

Re: Performance problem postgresql 9.5

2018-06-09 Thread Andreas Kretschmer
Am 08.06.2018 um 22:09 schrieb Alvaro Herrera: On 2018-Jun-08, Miguel Angel Sanchez Sandoval wrote: Hi guys, migrate from 8.4 to 9.5, all OK except that 2-3 days pass and the database experiences slowness, I execute the linux top command and it shows me a postgres user process executing a

pg_upgrade and wraparound

2018-06-09 Thread Alexander Shutyaev
Hello! I've been trying to upgrade a postgresql cluster from 9.6 to 10. I've executed the pg_upgrade with the following options: /usr/lib/postgresql/10/bin/pg_upgrade -b /usr/lib/postgresql/9.6/bin/ -B /usr/lib/postgresql/10/bin/ -d /var/lib/postgresql/9.6/main -D /var/lib/postgresql/10/main -o