Re: [GENERAL] database is not accepting commands

postgres 9.3 in ubuntu OS. Yes I did this : 1- service postgresql stop 2- /usr/lib/postgresql/9.3/bin/postgres --single -D /var/lib/postgresql/9.3/main -c config_file=/etc/postgresql/9.3/main/postgresql.conf dbname 3-vacuum verbose 4- vacumming processed and it shows tables being vacuumed but

Re: [GENERAL] database is not accepting commands

The version is 9.3 in ubuntu. yes i did it in standalone mode by using this command : //usr/lib/postgresql/9.3/bin/postgres --single -D /var/lib/postgresql/9.3/main -c config_file=/etc/postgresql/9.3/main/postgresql.conf dbname/ -- View this message in context:

Re: [GENERAL] improvements/feedback sought for a working query that looks a bit ugly and might be inefficient

On Tuesday, May 16, 2017, jonathan vanasco wrote: > > Everything here works fine - but after a handful of product iterations & > production adjustments, a query that handles a "task queue" across a few > tables looks a bit ugly. This is a far cry from ugly. > > My concern

[GENERAL] improvements/feedback sought for a working query that looks a bit ugly and might be inefficient

Everything here works fine - but after a handful of product iterations & production adjustments, a query that handles a "task queue" across a few tables looks a bit ugly. I'm wondering if anyone can see obvious improvements. There are 3 tables: upstream_provider task

Re: [GENERAL] sorry, too many clients already error

Sandeep Gupta writes: > I have set max_connection = 40. > The usage is somewhat not typical. It is basically > experiment runs that connect to the database > and dump results there. > The experiments connect through JDBC and > they close the connection when they are

[GENERAL] sorry, too many clients already error

I have set max_connection = 40. The usage is somewhat not typical. It is basically experiment runs that connect to the database and dump results there. The experiments connect through JDBC and they close the connection when they are done. I can verify that no more than 20 clients/experiments

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 05/16/2017 08:39 AM, Martin Goodson wrote: On 16/05/2017 15:58, Adrian Klaver wrote: For completeness what does: ls -al /usr/lib64/libssl.so show? (Trimming things down a bit to keep things a little bit more readable, now we've got the package dependencies issue sorted. Hopefully.

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

Martin Goodson writes: /bin/ld: warning: libssl.so.1.0.0, needed by /db_demo/app/postgres/9.6.2-3/lib/libpq.so, may conflict with libssl.so.10 /lib64/libldap_r-2.4.so.2: undefined reference to `ber_sockbuf_io_udp' collect2: error: ld returned 1

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 16/05/2017 16:39, Martin Goodson wrote: On 16/05/2017 15:58, Adrian Klaver wrote: /bin/ld: warning: libssl.so.1.0.0, needed by /db_demo/app/postgres/9.6.2-3/lib/libpq.so, may conflict with libssl.so.10 /lib64/libldap_r-2.4.so.2: undefined reference to `ber_sockbuf_io_udp' collect2: error:

Re: [GENERAL] storing large files in database - performance

On 2017-05-16 12:25:03 +, Eric Hill wrote: > I searched and found a few discussions of storing large files in the database > in the archives, but none that specifically address performance and how large > of files can realistically be stored in the database. > > > > I have a node.js

Re: [GENERAL] Different query plan used for the same query depending on how parameters are passed

David Chapman writes: > Here is the output of EXPLAIN ANALYZE on the two queries. > Index Scan using test_index_t1_t2 on test (cost=0.43..684.11 rows=71 > width=245) (actual time=0.022..1.147 rows=99 loops=1) > Index Cond: ((t1 = 'X'::bpchar) AND (t2 = ANY

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 16/05/2017 15:58, Adrian Klaver wrote: For completeness what does: ls -al /usr/lib64/libssl.so show? (Trimming things down a bit to keep things a little bit more readable, now we've got the package dependencies issue sorted. Hopefully. Hope that's OK?) I can see the following: $ ls

Re: [GENERAL] Different query plan used for the same query depending on how parameters are passed

Version is 'PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4), 64-bit' Here is the output of EXPLAIN ANALYZE on the two queries. Index Scan using test_index_t1_t2 on test (cost=0.43..684.11 rows=71 width=245) (actual time=0.022..1.147 rows=99

Re: [GENERAL] database is not accepting commands

On Tue, May 16, 2017 at 11:03 AM, Adrian Klaver wrote: > On 05/16/2017 01:28 AM, reem wrote: > >> We have 1.5 TB database that's shown an error and block all commands. >> The error is : >> "ERROR: database is not accepting commands to avoid wraparound data loss >> in

Re: [GENERAL] storing large files in database - performance

OK, thanks very much. It seems like my process is somehow flawed. I'll try removing some layers and see if I can figure out what is killing the performance. Eric > > Do these numbers surprise you? Are these files just too large for > storage in PostgreSQL to be practical? Could there be

Re: [GENERAL] database is not accepting commands

On 05/16/2017 01:28 AM, reem wrote: We have 1.5 TB database that's shown an error and block all commands. The error is : "ERROR: database is not accepting commands to avoid wraparound data loss in database "dbname" HINT: Stop the postmaster and use a standalone backend to vacuum that database.

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 05/16/2017 07:22 AM, Martin Goodson wrote: On 16/05/2017 14:42, Adrian Klaver wrote: On 05/16/2017 04:36 AM, Martin Goodson wrote: On 15/05/2017 00:17, Martin Goodson wrote: That list would be: systemd libxslt-devel pam-devel openssl-devel readline-devel libmemcached-devel libicu-devel

Re: [GENERAL] storing large files in database - performance

John R Pierce schrieb am 16.05.2017 um 16:44: > On 5/16/2017 7:35 AM, Thomas Kellerer wrote: >> When my (JDBC based) SQL client and the database server are on the same >> computer... > > node.js is Javascript, not java w/ jdbc I know that. I mentioned JDBC so that it's clear that the timings

Re: [GENERAL] storing large files in database - performance

On 05/16/2017 07:44 AM, John R Pierce wrote: On 5/16/2017 7:35 AM, Thomas Kellerer wrote: When my (JDBC based) SQL client and the database server are on the same computer... node.js is Javascript, not java w/ jdbc I think it was more a point of comparison, like my using a Python example.

Re: [GENERAL] Help: Installing 9.6 breaks local connections to 9.2 on Centos 6.9

Magnus Hagander writes: > On Tue, May 16, 2017 at 10:00 AM, Devrim Gündüz wrote: >> Not sure whether we should *fix* this or not on RPM side. This may break >> some of the existing installations, right? > Changing that in a minor version seems like a

Re: [GENERAL] storing large files in database - performance

On 5/16/2017 5:25 AM, Eric Hill wrote: I do have the Sequelize ORM and the pg driver in between my code and the database. Can you try a similar test without the ORM, just going straight from node.js to sql ? -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general

Re: [GENERAL] storing large files in database - performance

On 5/16/2017 7:35 AM, Thomas Kellerer wrote: When my (JDBC based) SQL client and the database server are on the same computer... node.js is Javascript, not java w/ jdbc -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

Re: [GENERAL] Different query plan used for the same query depending on how parameters are passed

From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of David Chapman Sent: Tuesday, May 16, 2017 9:02 AM To: pgsql-general@postgresql.org Subject: [GENERAL] Different query plan used for the same query depending on how parameters are passed Attention:

Re: [GENERAL] storing large files in database - performance

On 05/16/2017 05:25 AM, Eric Hill wrote: Hey, I searched and found a few discussions of storing large files in the database in the archives, but none that specifically address performance and how large of files can realistically be stored in the database. I have a node.js application using

Re: [GENERAL] storing large files in database - performance

Eric Hill schrieb am 16.05.2017 um 14:25: > I have a node.js application using PostgreSQL to store uploaded > files. The column in which I am storing the file contents is of type > “bytea” with “Storage” type set to “EXTENDED”. Storing a 12.5 MB file > is taking 10 seconds, and storing a 25MB file

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 16/05/2017 14:42, Adrian Klaver wrote: On 05/16/2017 04:36 AM, Martin Goodson wrote: On 15/05/2017 00:17, Martin Goodson wrote: Tomorrow I'll have to see about getting that set-up on an RHEL 7 box :) Thank you so much, everybody, for your help! It's been invaluable! Regards, Martin.

Re: [GENERAL] Different query plan used for the same query depending on how parameters are passed

On 05/16/2017 06:01 AM, David Chapman wrote: I have a table that includes two text columns t1 and t2, and a composite index on these columns. When issuing a query of the following form: SELECT * FROM test WHERE t1 = 'X' and t2 = ANY(ARRAY['Y1', 'Y2', ..]) I have observed that it will use the

Re: [GENERAL] Help: Installing 9.6 breaks local connections to 9.2 on Centos 6.9

On 05/16/2017 01:00 AM, Devrim Gündüz wrote: Hi, On Mon, 2017-05-15 at 22:35 -0700, Ken Tanzer wrote: https://redmine.postgresql.org/issues/2409 Not sure whether we should *fix* this or not on RPM side. This may break some of the existing installations, right? I'm not objecting, just

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 05/16/2017 04:36 AM, Martin Goodson wrote: On 15/05/2017 00:17, Martin Goodson wrote: Tomorrow I'll have to see about getting that set-up on an RHEL 7 box :) Thank you so much, everybody, for your help! It's been invaluable! Regards, Martin. *Sigh*. And things were going so well.

Re: [GENERAL] storing large files in database - performance

Eric Hill wrote: > I am storing the file contents is of type "bytea" with "Storage" type set to > "EXTENDED". Storing a 12.5 MB file is taking 10 seconds That seems really slow indeed. Can you import the same file to the same server with psql's \lo_import command and see how much time

[GENERAL] Different query plan used for the same query depending on how parameters are passed

I have a table that includes two text columns t1 and t2, and a composite index on these columns. When issuing a query of the following form: SELECT * FROM test WHERE t1 = 'X' and t2 = ANY(ARRAY['Y1', 'Y2', ..]) I have observed that it will use the index and have reasonable performance if the

[GENERAL] PostgreSQL RPMs for PPC64LE are released

The PostgreSQL YUM Repository Project is happy to announce RPMs of PostgreSQL 9.6 and related software for Power8 Little Endian (PPC64LE) platforms on RHEL 7 and CentOS 7. We want to thank IBM and EnterpriseDB for sponsoring hardware and manpower for this project. These packages follow the same

[GENERAL] storing large files in database - performance

Hey, I searched and found a few discussions of storing large files in the database in the archives, but none that specifically address performance and how large of files can realistically be stored in the database. I have a node.js application using PostgreSQL to store uploaded files. The

Re: [GENERAL] EnterpriseDB installed PostgreSQL 9.6 vs. REPMGR. Round 4 - compilation issues on RHEL 7.2

On 15/05/2017 00:17, Martin Goodson wrote: Tomorrow I'll have to see about getting that set-up on an RHEL 7 box :) Thank you so much, everybody, for your help! It's been invaluable! Regards, Martin. *Sigh*. And things were going so well. With Adrian and Devrim's help I was able to get

Re: [GENERAL] Help: Installing 9.6 breaks local connections to 9.2 on Centos 6.9

On Tue, May 16, 2017 at 10:00 AM, Devrim Gündüz wrote: > > Hi, > > On Mon, 2017-05-15 at 22:35 -0700, Ken Tanzer wrote: > > https://redmine.postgresql.org/issues/2409 > > Not sure whether we should *fix* this or not on RPM side. This may break > some > of the existing

[GENERAL] database is not accepting commands

We have 1.5 TB database that's shown an error and block all commands. The error is : "ERROR: database is not accepting commands to avoid wraparound data loss in database "dbname" HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll

Re: [GENERAL] Help: Installing 9.6 breaks local connections to 9.2 on Centos 6.9

Hi, On Mon, 2017-05-15 at 22:35 -0700, Ken Tanzer wrote: > https://redmine.postgresql.org/issues/2409 Not sure whether we should *fix* this or not on RPM side. This may break some of the existing installations, right? I'm not objecting, just asking for opinions. Regards, -- Devrim Gündüz

Re: [GENERAL] Postgres intermittent connection errors: psql.bin: could not connect to server: Cannot assign requested address

Vamsi Patchipulusu writes: > Error: psql.bin: could not connect to server: Cannot assign > requested address > Is the server running on host "abchost.corp.xyz.com" > (xxx.xxx.xxx.xxx) and accepting > TCP/IP connections on port 5432? Googling

Re: [GENERAL] Postgres intermittent connection errors: psql.bin: could not connect to server: Cannot assign requested address

On Monday, May 15, 2017, Vamsi Patchipulusu wrote: > > Error: psql.bin: could not connect to server: Cannot assign > requested address > > Is the server running on host "abchost.corp.xyz.com" > (xxx.xxx.xxx.xxx) and accepting > > TCP/IP