[GENERAL] Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ?

Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ? Can i set it to other value ? If i extend or decrease it , can it affect the performance of sending message? 张晓博 研发二部 北京人大金仓信息技术股份有限公司 地址：北京市海淀区上地西路八号院上地科技大厦4号楼501 邮编：100085 电话：(010) 5885 1118 - 8450 手机：15311394463 邮箱：xbzh

[GENERAL] authentication failure

Hi, I am trying to login from psql and consistently getting a "psql: FATAL: password authentication failed for user "xyz"" for all users. I am not being prompted for a password at all. I faced a similar issue sometime ago because there was a .pgpass file and it had wrong entries. This time there i

Re: [GENERAL] authentication failure

Try "psql -W" for prompting the password forcefully. On Fri, Jan 3, 2014 at 2:46 PM, Jayadevan M wrote: > Hi, > I am trying to login from psql and consistently getting a > "psql: FATAL: password authentication failed for user "xyz"" for all > users. I am not being prompted for a password at all

Re: [GENERAL] Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 03/01/2014 09:47, xbzhang ha scritto: > Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ? > Can i set it to other value ? In principle, it is just an arbitrary amount by which to increase the I/O buffer size. Of course it has to ta

Re: [GENERAL] authentication failure

Nope - psql -W psql: FATAL: password authentication failed for user "postgres" On Fri, Jan 3, 2014 at 2:49 PM, Ashesh Vashi wrote: > Try "psql -W" for prompting the password forcefully. > > > On Fri, Jan 3, 2014 at 2:46 PM, Jayadevan M > wrote: > >> Hi, >> I am trying to login from psql and c

Re: [GENERAL] authentication failure

Hi, On Fri, Jan 3, 2014 at 3:32 PM, Jayadevan M wrote: > Nope - > psql -W > psql: FATAL: password authentication failed for user "postgres" > > There might be possible of the user's password expiration. Make the user's local authentication as trust, and reload the postgres instance, and check th

Re: [GENERAL] authentication failure

On Fri, Jan 3, 2014 at 4:16 AM, Jayadevan M wrote: > Hi, > I am trying to login from psql and consistently getting a > "psql: FATAL: password authentication failed for user "xyz"" for all > users. I am not being prompted for a password at all. I faced a similar > issue sometime ago because there

Re: [GENERAL] authentication failure

I am able to login from the non-chroot environment. So it is not an issue with pg_hba.conf and not an issue of password expiration. Is there a debug psql option? On Fri, Jan 3, 2014 at 5:09 PM, Chris Curvey wrote: > > > > On Fri, Jan 3, 2014 at 4:16 AM, Jayadevan M > wrote: > >> Hi, >> I am

Re: [GENERAL] authentication failure

On Fri, Jan 3, 2014 at 5:13 PM, Jayadevan M wrote: > I am able to login from the non-chroot environment. So it is not an issue > with pg_hba.conf and not an issue of password expiration. Is there a debug > psql option? > > OK. Have you checked the PGPASSWORD environment variable, from where you a

Re: [GENERAL] authentication failure

Yes. All the basic checks I have done. I upgraded from CENTOs 6.4 to 6.5. Another interesting thing - if I su - postgres and then try, it works. So it has something to do with the chrt user (root) settings. On Fri, Jan 3, 2014 at 5:36 PM, dinesh kumar wrote: > > On Fri, Jan 3, 2014 at 5:13 PM, J

Re: [GENERAL] authentication failure

On 01/03/2014 04:54 AM, Jayadevan M wrote: Yes. All the basic checks I have done. I upgraded from CENTOs 6.4 to 6.5. Another interesting thing - if I su - postgres and then try, it works. So it has something to do with the chrt user (root) settings. It might be helpful to detail what are the '

Re: [GENERAL] Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ?

xbzhang writes: > Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ? Traditionally, at least, that was the size of pipe buffers in Unix machines, so in principle this is the most optimal chunk size for sending data across a Unix socket. I have no idea though if that's still true in

Re: [GENERAL] authentication failure

Adrian Klaver writes: > On 01/03/2014 04:54 AM, Jayadevan M wrote: >> Yes. All the basic checks I have done. I upgraded from CENTOs 6.4 to >> 6.5. Another interesting thing - if I su - postgres and then try, it >> works. So it has something to do with the chrt user (root) settings. > It might be

Re: [GENERAL] Why the size (PQ_BUFFER_SIZE) of backend send buffers is 8192 ?

On Fri, Jan 03, 2014 at 10:00:42AM -0500, Tom Lane wrote: > know the end-to-end MTU size with any reliability. Well, you could try PMTU discovery, though I agree that it's not great. It also seems pretty low-level for something like the DBMS to be doing. A -- Andrew Sullivan a...@crankycanuck.

Re: [GENERAL] bulk loading table via join of 2 large staging tables

On Tue, 31 Dec 2013 02:23:30 +, Brent Wood wrote: > This should help... In each temporary table convert the time parts to > a timestamp, then create an index on each of these, then join on the > timestamp. [...] Thank you, these were very useful suggestions, and lead to a very efficient ta

[GENERAL] Suddenly all tables were gone

Yesterday I found that one of the databases in my database cluster suddenly lost all its tables. A \dt in psql showed nothing. I'm not sure how or when it happened, but it was either due to an upgrade of postgres from 9.1 to 9.3 or else something going wrong with pg_dump. Has anyone had this happe

Re: [GENERAL] pg_largeobject related issue with 9.2

sramay wrote: > I am having a application which was running on Jboss 5 with > Hibernate and PostgreSQL 9.2.  Due to media corruption.  Data > without largeobject was restored  and largeobject I restored from > some other source. > > Now the application is giving error  eventhough largeobject is >

Re: [GENERAL] Suddenly all tables were gone

Moshe Jacobson writes: > Yesterday I found that one of the databases in my database cluster suddenly > lost all its tables. A \dt in psql showed nothing. I'm not sure how or when > it happened, but it was either due to an upgrade of postgres from 9.1 to > 9.3 or else something going wrong with pg_

[GENERAL] Creating an index alters the results returned

Hi, Running postgres 9.1.11 + postgresql-9.3-1100.jdbc41.jar, I experience a strange phenomenon using indexes. I have the following schema: CREATE TABLE wplog (id serial NOT NULL,ts timestamp without time zone, sensor1 real, sensor2 real, noiselevel smallint, CONSTRAINT wplog_pkey PRIMARY KEY (id

Re: [GENERAL] Suddenly all tables were gone

> Yesterday I found that one of the databases in my database cluster suddenly > lost all its tables. > A \dt in psql showed nothing. Is there any chance this could be a search_path issue? Do you have a ~/.psqlrc? Or are you sure you're in the right database? If you are connecting as the postgres

Re: [GENERAL] Full text search on partial URLs

On 11/15/2013 07:40 PM, Zev Benjamin wrote: One problem that I've run into here is that I would also like to highlight matched text in my application. For my existing search solution, I do this with ts_headline. For partial matches, it's unfortunately not just a matter of searching for the tex

Re: [GENERAL] Suddenly all tables were gone

On Fri, Jan 3, 2014 at 2:42 PM, Tom Lane wrote: Could we see the output from pg_controldata? Here you go. The problem database has already been dropped and re-created, BTW: (0)(0j)[root@staging /var/lib/pgsql/9.3]# pg_controldata pg_control version number:937 Catalog version number:

Re: [GENERAL] Full text search on partial URLs

On 11/15/2013 07:40 PM, Zev Benjamin wrote: One problem that I've run into here is that I would also like to highlight matched text in my application. For my existing search solution, I do this with ts_headline. For partial matches, it's unfortunately not just a matter of searching for the tex

Re: [GENERAL] Suddenly all tables were gone

On Fri, Jan 3, 2014 at 3:02 PM, Paul Jungwirth wrote: > Is there any chance this could be a search_path issue? Do you have a > ~/.psqlrc? > > Or are you sure you're in the right database? If you are connecting as > the postgres user, are you using \c? > Yeah, I was connecting as postgres, no spec

Re: [GENERAL] Creating an index alters the results returned

> -Original Message- > From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general- > ow...@postgresql.org] On Behalf Of Clemens Eisserer > Sent: Friday, January 03, 2014 3:00 PM > To: pgsql-general@postgresql.org; pgsql-j...@postgresql.org > Subject: [GENERAL] Creating an index alters t

Re: [GENERAL] Suddenly all tables were gone

Moshe Jacobson writes: > On Fri, Jan 3, 2014 at 2:42 PM, Tom Lane wrote: > Could we see the output from pg_controldata? > Here you go. The problem database has already been dropped and re-created, Then the evidence is pretty much gone I'm afraid :-( > Latest checkpoint's NextXID: 0/32

Re: [GENERAL] Suddenly all tables were gone

On 1/3/2014 12:18 PM, Moshe Jacobson wrote: Yeah, I was connecting as postgres, no special search_path, same config was working earlier. No harm in asking! it was working AFTER the 9.1->9.3 upgrade ? -- john r pierce 37N 122W somewhere on the middle of t

Re: [GENERAL] Suddenly all tables were gone

On Fri, Jan 3, 2014 at 3:59 PM, John R Pierce wrote: > it was working AFTER the 9.1->9.3 upgrade ? > I think it was for some amount of time, since I used pg_dump to dump the contents, and pg_restore to restore those contents into another database in the same cluster. I was using the database to

Re: [JDBC] [GENERAL] Creating an index alters the results returned

Yes, please check the server logs. There should be no reason whatsoever that JDBC would effect the results if the query is the same Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Jan 3, 2014 at 3:42 PM, Igor Neyman wrote: > > -Original Message- > > From: pgs

[GENERAL] is psql treatment of line-endings configurable?

Using psql 9.3 against a 9.0 server. I send queries to the server via a windows based client which uses and sends "\r\n" for the newline. When running this query: SELECT procpid, current_query, client_addr, xact_start, query_start FROM pg_stat_activity The contents of current_query display as:

Re: [GENERAL] Creating an index alters the results returned

On 01/03/2014 11:59 AM, Clemens Eisserer wrote: Hi, Running postgres 9.1.11 + postgresql-9.3-1100.jdbc41.jar, I experience a strange phenomenon using indexes. I have the following schema: CREATE TABLE wplog (id serial NOT NULL,ts timestamp without time zone, sensor1 real, sensor2 real, noiselev

Re: [GENERAL] Creating an index alters the results returned

On Fri, Jan 3, 2014 at 5:55 PM, Adrian Klaver wrote: > Only thing I can think of is the JDBC driver and Postgres have a difference > of opinion on the precision of double precision. What happens if you > eliminate the double precision cast? This brings up the point as well, don't use floating po

Re: [JDBC] [GENERAL] Creating an index alters the results returned

Regardless of type used… the driver and server should agree on the results. On Jan 3, 2014, at 6:06 PM, Scott Marlowe wrote: > On Fri, Jan 3, 2014 at 5:55 PM, Adrian Klaver wrote: > >> Only thing I can think of is the JDBC driver and Postgres have a difference >> of opinion on the precision of

Re: [GENERAL] Suddenly all tables were gone

On 01/03/2014 01:18 PM, Moshe Jacobson wrote: On Fri, Jan 3, 2014 at 3:59 PM, John R Pierce mailto:pie...@hogranch.com>> wrote: it was working AFTER the 9.1->9.3 upgrade ? I think it was for some amount of time, since I used pg_dump to dump the contents, and pg_restore to restore those co

[GENERAL] debian 9.3 install history file permission denied

To get 9.3 installed, postgresql was completely removed (incl folders) and reinstalled. Had to manually check postgresql on the services menu to launch the server. All seems to work but getting error on \q with history file permission denied. What is best way to fix this ? -- Sent via pg

[GENERAL] returning json data row from json query

select * from users where jsondata->>'username' = 'jdoe' works but returns field names, etc besides the data row.how can we get json data back ? select row_to_json from users where jsondata->>'username'='jdoe' didn't work. any ideas ? thks. -- Sent via pgsql-general mailing list (pgsql

Re: [GENERAL] authentication failure

There is only one instance - ps -eaf | grep bin/postgres | grep -v grep postgres 3203 1 0 2013 ?00:02:04 /usr/pgsql-9.3/bin/postgres The basic checks I did - Connectivity from other machines work (so server is accessible) No .pgpass file in the system Able to login as postgres and

Re: [GENERAL] returning json data row from json query

john.tiger wrote > select * from users where jsondata->>'username' = 'jdoe' works but > returns field names, etc besides the data row.how can we get json > data back ? > > select row_to_json from users where jsondata->>'username'='jdoe' didn't > work. > > any ideas ? thks. Using what clie