Re: [BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
Hey, I found something that finally clears netstat's recv-q with async notifies. I don't quite understand what's going on, so any enlightenment would be greatly appreciated. As near as I can figure, the client doesn't appear to read the notifies until it sends a notify of its own. Then it reads all pending notifies at once and clears the recv-q. For instance, I can open up two connections on my test server and illustrate the problem. Here's the netstat before everything. [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp0 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb= listen req; LISTEN Connection 2: csdb= notify req; NOTIFY (repeat 5 times) Netstat as of now (after 5 notifies): [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp 70 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb= notify req; NOTIFY Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7267. Netstat as of now: [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp0 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED This does make some sense given our code (the listening connection only listens, it never sends out notifies of its own). However, this doesn't seem like expected behavior. I found nothing in the docs to suggest this being the norm, and it seems odd to require a connection to issue a notify itself before being able to read pending notifies from another connection. Any ideas? Peter ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] some information
how to connect postgresql database with perl Please if server ip:192.168.0.1 server name=abcd we using Slackware 10.2 kernel 2.6.17 which suport postgresql version rakesh - Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
Re: [BUGS] some information
Hello it isn't bug! PostgreSQL's driver for perl http://search.cpan.org/~dbdpg/DBD-Pg-1.49/Pg.pm look to postgresql.conf (port) and pg_hba.conf (enable access) Regards Pavel Stehule 2007/8/17, rakesh kumar [EMAIL PROTECTED]: how to connect postgresql database with perl Please if server ip:192.168.0.1 server name=abcd we using Slackware 10.2 kernel 2.6.17 which suport postgresql version rakesh Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 16, 2007 at 05:41:32PM -0500, Peter Koczan wrote: Hey, I found something that finally clears netstat's recv-q with async notifies. I don't quite understand what's going on, so any enlightenment would be greatly appreciated. As near as I can figure, the client doesn't appear to read the notifies until it sends a notify of its own. Then it reads all pending notifies at once and clears the recv-q. For instance, I can open up two connections on my test server and illustrate the problem. Here's the netstat before everything. [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp0 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb= listen req; LISTEN Connection 2: csdb= notify req; NOTIFY (repeat 5 times) Netstat as of now (after 5 notifies): [EMAIL PROTECTED] ~ $ netstat | grep mitchell tcp 70 0 ator.cs.wisc.edu:34279 mitchell.cs.wisc:postgresql ESTABLISHED tcp0 0 ator.cs.wisc.edu:34280 mitchell.cs.wisc:postgresql ESTABLISHED Connection 1: csdb= notify req; NOTIFY Asynchronous notification req received from server process with PID 7268. Asynchronous notification req received from server process with PID 7268. [...] Hm. To me it looks like the first psql session isn't prepared to gather async notifies (checking...) indeed, psql only checks for async notifies when issuing commands (you don't have to issue a NOTIFY in Connection 1 to receive the pending notifies -- *any* request directed to the server would do). Any ideas? If you see the queue building up as above, the problem lies almost certainly on the client not gathering the notifies. The backend is obviously willing to talk to you :-) I'd look for the problem in the client library (It's DBD::Pg in your real case, isn't it?) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGxZCABcgs9XrR2kYRAkAsAJ9lvE86sUMQstU0S08/eWT64XqgpwCfZzjt XVQrPm6b82m47QDFxcGyFTg= =Omtb -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3547: getting error during salient Installation
The following bug has been logged online: Bug reference: 3547 Logged by: Abhay Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: XP , window 2000 Description:getting error during salient Installation Details: We need salient installation of postgresql.We run the command C:\msiexec /l*v C:\postgresql-8.2.4-1\log.txt /i C:\postgresql-8.2.4-1\postgr esql-8.2-int.msi /qn INTERNALLAUNCH=1 SERVICEDOMAIN=%COMPUTERNAME% SERVICEACCO UNT=postgre SERVICEPASSWORD=secret123 SUPERPASSWORD=secret123; then we got the error on log file MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 1708 MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 2205 2: 3: Error MSI (s) (CC:C0) [12:55:28:000]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 MSI (s) (CC:C0) [12:55:28:015]: Note: 1: 2205 2: 3: Error MSI (s) (CC:C0) [12:55:28:015]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (CC:C0) [12:55:28:015]: Product: PostgreSQL 8.2 -- Installation failed. MSI (s) (CC:C0) [12:55:28:015]: Cleaning up uninstalled install packages, if any exist what is doing wrong. please help ASAP. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] error while starting database
I am using postgres 7.0 on linux platform. My java application was running fine ,but i got this message Connection refused. Check that the hostname and port is correct, and that the postmaster is r unning with the -i flag, which enables TCP/IP networking. at org.postgresql.Connection.openConnection(Connection.java:123) at org.postgresql.Driver.connect(Driver.java:116) at java.sql.DriverManager.getConnection(DriverManager.java:517) at java.sql.DriverManager.getConnection(DriverManager.java:177) at SendGrpSmpp.readSMPPtable(SendGrpSmpp.java:219) at SendGrpSmpp.run(SendGrpSmpp.java:96) When i am connecting as su via su - postgres at bash: when i give psql Database Name It is giving error: psql: connectDBStart() -- connect() failed: No such file or directory Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'? when i am using pg_ctl status command: it gives output: pg_ctl: postmaster is running (pid: 776) options are: /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data -B 64 -b /usr/bin/postgres -i -N 32 when i am using pg_ctl stop it gives /usr/bin/pg_ctl: kill: (776) - No such pid postmaster successfully shut down. when i am using pg_ctl restart it gives bash-2.04$ pg_ctl restart /usr/bin/pg_ctl: kill: (776) - No such pid Waiting for postmaster shutting down...pg_ctl: postmaster does not shut down when i am giving pg_ctl start: pg_ctl: It seems another postmaster is running. Try to start postmaster anyway. FATAL: StreamServerPort: bind() failed: No such file or directory Is another postmaster already running on that port? If not, remove socket node (/tmp/.s.PGSQL.5432) and retry. pg_ctl: Cannot start postmaster. Is another postmaster is running? bash-2.04$ /usr/bin/postmaster: cannot create UNIX stream port. Expecting your kind help on urgent. Regards-- NItin Saxena
Re: [BUGS] error while starting database
PostgreSQL version 7.0 is really, really out of date, but as far as I know, it should still work. I generally use ps -ax | grep postges to see if there is a postgres process running. Also, I use netstat -a to see open sockets and listening servers. Have you removed the socket file in /tmp and tried to start the server? You may also want to check the server log to see if there is any indication of why it crashed. Once you clean up the residue from the server that abended, you'll be able to start it again, unless there are serious problems with the database. I've only seen one case where I couldn't get the server restarted, though, and that was after a hard drive failure caused corruption in several files. Even then, I was able to recover everything. BTW: the socket file (/tmp/.s.PGSQL.5432) will be a hidden file. You'll need to ls -a /tmp to see it. You can just rm -f / tmp/.s.PGSQL.5432 as root and that should clean it up for you. p.s. This is not a bug, and even if it was, I'm sure version 7.0 is no longer supported. You may want to use a different list if you require additional assistance. On Aug 17, 2007, at 10:31 AM, Nitin Saxena wrote: I am using postgres 7.0 on linux platform. My java application was running fine ,but i got this message Connection refused. Check that the hostname and port is correct, and that the postmaster is r unning with the -i flag, which enables TCP/IP networking. at org.postgresql.Connection.openConnection(Connection.java:123) at org.postgresql.Driver.connect(Driver.java:116) at java.sql.DriverManager.getConnection(DriverManager.java:517) at java.sql.DriverManager.getConnection(DriverManager.java:177) at SendGrpSmpp.readSMPPtable(SendGrpSmpp.java:219) at SendGrpSmpp.run(SendGrpSmpp.java:96) When i am connecting as su via su - postgres at bash: when i give psql Database Name It is giving error: psql: connectDBStart() -- connect() failed: No such file or directory Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'? when i am using pg_ctl status command: it gives output: pg_ctl: postmaster is running (pid: 776) options are: /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data -B 64 -b /usr/bin/postgres -i -N 32 when i am using pg_ctl stop it gives /usr/bin/pg_ctl: kill: (776) - No such pid postmaster successfully shut down. when i am using pg_ctl restart it gives bash-2.04$ pg_ctl restart /usr/bin/pg_ctl: kill: (776) - No such pid Waiting for postmaster shutting down...pg_ ctl: postmaster does not shut down when i am giving pg_ctl start: pg_ctl: It seems another postmaster is running. Try to start postmaster anyway. FATAL: StreamServerPort: bind() failed: No such file or directory Is another postmaster already running on that port? If not, remove socket node (/tmp/.s.PGSQL.5432) and retry. pg_ctl: Cannot start postmaster. Is another postmaster is running? bash-2.04$ /usr/bin/postmaster: cannot create UNIX stream port. Expecting your kind help on urgent. Regards-- NItin Saxena Douglas Toltzman [EMAIL PROTECTED] (910) 526-5938
Re: [BUGS] error while starting database
Nitin Saxena [EMAIL PROTECTED] writes: I am using postgres 7.0 on linux platform. Egad. At first I thought that was a typo, but if psql really spelled its error message just like that, it must indeed be 7.0 or older :-(. Do yourself a favor and get onto a newer version, NOW. Not tomorrow. There are hundreds if not thousands of known bugs in 7.0 that are fixed in more modern versions. Some of them *will* destroy your data. As for getting out of the immediate problem, it looks like there is something wrong with the directory that PG wants to put its socket file into. Perhaps /tmp is not there or not world writable? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #3548: When quickly switching between databases the server lags behind
The following bug has been logged online:
Bug reference: 3548
Logged by: Daniel Heyder
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux (Red Hat EL4 Update 4 + PostgreSQL 8.2.4 update +
compat libraries)
Description:When quickly switching between databases the server lags
behind
Details:
Hi,
when I do quick PQconnectdb give the connection something to do PQfinish the
connection and PQconnectdb to another database the database server does not
keep up, neither does PQconnectdb or PQfinish block until the work is
complete. This is annoying when I want to delete the still working database.
(Causes an error as it is still in use.)
Here some code which demonstrates the problem (make sure it is the only
process accessing the database):
#include libpq-fe.h
#include string.h
int main()
{
char *pq_db;
char *tb_db;
PGconn *conn;
PGresult *res;
for (int x = 0; x 2000; x++)
{
conn = PQconnectdb(host=127.0.0.1 dbname=postgres port=5432);
pq_db = PQdb(conn);
res = PQexec(conn, SELECT * FROM pg_catalog.pg_stat_activity ORDER BY
usename, procpid;);
tb_db = PQgetvalue(res, 0, 1);
if (strcmp(pq_db, tb_db) != 0)
{
fprintf(stderr, * ERROR WRONG DATABASE OPEN (pq=%s, tb=%s)
**\n, pq_db, tb_db);
return 1;
}
PQclear(res);
PQexec(conn, CREATE TABLE x1 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x2 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x3 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x4 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x5 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x6 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x7 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x8 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, CREATE TABLE x9 (x integer PRIMARY KEY, y integer,z
timestamp without time zone,u timestamp without time zone););
PQexec(conn, DROP TABLE x1);
PQexec(conn, DROP TABLE x2);
PQexec(conn, DROP TABLE x3);
PQexec(conn, DROP TABLE x4);
PQexec(conn, DROP TABLE x5);
PQexec(conn, DROP TABLE x6);
PQexec(conn, DROP TABLE x7);
PQexec(conn, DROP TABLE x8);
PQexec(conn, DROP TABLE x9);
PQfinish(conn);
conn = PQconnectdb(host=127.0.0.1 dbname=template1 user=csntool
password=comsoft port=5432);
pq_db = PQdb(conn);
res = PQexec(conn, SELECT * FROM pg_catalog.pg_stat_activity ORDER BY
usename, procpid;);
tb_db = PQgetvalue(res, 0, 1);
if (strcmp(pq_db, tb_db) != 0)
{
fprintf(stderr, * ERROR WRONG DATABASE OPEN (pq=%s, tb=%s)
**\n, pq_db, tb_db);
return 1;
}
PQclear(res);
PQfinish(conn);
}
return 0;
}
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
Peter Koczan wrote: Hm. To me it looks like the first psql session isn't prepared to gather async notifies (checking...) indeed, psql only checks for async notifies when issuing commands (you don't have to issue a NOTIFY in Connection 1 to receive the pending notifies -- *any* request directed to the server would do). If you see the queue building up as above, the problem lies almost certainly on the client not gathering the notifies. The backend is obviously willing to talk to you :-) I'd look for the problem in the client library (It's DBD::Pg in your real case, isn't it?) *Light bulb lights up* AhI see what's going on now. I think I have enough information to test and fix the problem on our end. Thank you all for your help and patience. This can be considered resolved. Please share the ending with us, I'm really curious after following this thread :). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3548: When quickly switching between databases the server lags behind
Daniel Heyder [EMAIL PROTECTED] writes: when I do quick PQconnectdb give the connection something to do PQfinish the connection and PQconnectdb to another database the database server does not keep up, neither does PQconnectdb or PQfinish block until the work is complete. This is annoying when I want to delete the still working database. As of 8.3, DROP DATABASE will wait a little bit to see if conflicting sessions terminate. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3504: Some listening sessions never return from writing, problems ensue
Hm. To me it looks like the first psql session isn't prepared to gather async notifies (checking...) indeed, psql only checks for async notifies when issuing commands (you don't have to issue a NOTIFY in Connection 1 to receive the pending notifies -- *any* request directed to the server would do). If you see the queue building up as above, the problem lies almost certainly on the client not gathering the notifies. The backend is obviously willing to talk to you :-) I'd look for the problem in the client library (It's DBD::Pg in your real case, isn't it?) *Light bulb lights up* AhI see what's going on now. I think I have enough information to test and fix the problem on our end. Thank you all for your help and patience. This can be considered resolved. Peter ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3544: SQLException from JDBC driver
On Thu, 16 Aug 2007, Scott Harper wrote: The following bug has been logged online: Bug reference: 3544 PostgreSQL version: 8.1.9 Operating system: Debian Linux (2.6.18-4-486) Description:SQLException from JDBC driver Details: I have installed PostgreSQL 8.1 via the Debian package manager (APT) -- installed the package postgresql-8.1. We are running Sun Java 5, Apache 2, and Tomcat 5.5. From the discussion at http://jdbc.postgresql.org/download.html, I have determined that I should be using the 8.1-410 JDBC 3 driver. I downloaded the driver, and it is bundled into my servlet's war file in WEB-INF/lib. When the servlet makes the DriverManager.getConnection() call, the following exception is thrown: org.postgresql.util.PSQLException: Something unusual has occured to cause the driver to fail. Please report this exception. This exception is most likely caused by a permission denied error because you are running the tomcat server with a security policy. The driver should be placed in $CATALINA_HOME/common/lib instead of a war file. Kris Jurka ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
