Re: [BUGS] Deadlock condition in driver
Previously we did not want to move to nio to be able to support older JDK versions, but with the next major release we're ready to drop that support. If you have this code, I'd certainly be interested in looking at it. One of the big drawbacks of breaking up a single execute call into multiple batches is that in autocommit mode you would get one transaction per batch instead of the previous behavior of one transaction for the whole execute call. Kris Jurka On Thu, 22 May 2008, Richard Evans wrote: We hit this problem and modified the driver to use non-blocking IO to fix it. You lose some of the more unusual features of the driver (such as switching the socket after open), but it does fix the blocking. Richard Evans On Wed, 21 May 2008, Daniel Migowski wrote: I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). We already consider this case for batch execution and break the batch into an internal size that we expect is safe from deadlock. It looks like we should be doing the same for these one query batches. I'm not sure how tough that will be, but I'll take a look. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Deadlock condition in driver
We hit this problem and modified the driver to use non-blocking IO to fix it. You lose some of the more unusual features of the driver (such as switching the socket after open), but it does fix the blocking. Richard Evans On Wed, 21 May 2008, Daniel Migowski wrote: I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). We already consider this case for batch execution and break the batch into an internal size that we expect is safe from deadlock. It looks like we should be doing the same for these one query batches. I'm not sure how tough that will be, but I'll take a look. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] error message "psql: expected authentication request from server, but received " when using psql to connect remote database
Heikki Linnakangas, Thanks for your quick response; the server we used is 8.1.4, The error when using client 8.1.4, > psql -U or -p -d testdb -h localhost Output: psql: expected authentication request from server, but received when used 8.0.3, no problem, > psql -U or -p -d testdb -h localhost Output: Password: Then enter password, it can log in and do all operation. Thanks, Justin -Original Message- From: Heikki Linnakangas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 8:14 PM To: TIAN Justin Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] error message "psql: expected authentication request from server, but received " when using psql to connect remote database TIAN Justin wrote: > I met an error, when psql client version is 8.1.4, I use it to connect > to remote database or local database, such as "psql -U name -p -d > -h ", it will prompt error message "psql: expected > authentication request from server, but received ", but if the client > version is 8.0.3, there is no problem, I don't know why, does it the > configuration problem? Please post the exact output you're getting in both cases. What version is the server? You should upgrade to the latest minor version, which is 8.1.11 for the 8.1 series, and 8.0.15 for the 8.0 series -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4186: set lc_messages does not work
The following bug has been logged online: Bug reference: 4186 Logged by: Thomas H Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Windows 2003 Description:set lc_messages does not work Details: the patch discussed here [1] that supposedly made the win32 msvc builds use lc_locale properly has flaws. while indeed it does force pgsql to use the native win32 locale for error messages (before 8.3.1, system messages were always english), it broke the functionality to actually have the lc_messages locale set manually through conf or in a user session. the following output is from a win2003 system with German_Switzerland.1252 locale. the queries are identically to the one used as examples by the patch author. i have added a "select x;" to trigger a system error message to show that its actually misbehaving - all output is always in (swiss) german despite the set locale. - thomas [1] http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php Dies ist psql 8.3.1, das interaktive PostgreSQL-Terminal. Geben Sie ein: \copyright für Urheberrechtsinformationen \h für Hilfe über SQL-Anweisungen \? für Hilfe über interne Anweisungen \g oder Semikolon, um eine Anfrage auszuführen \q um zu beenden Warnung: Konsolencodeseite (850) unterscheidet sich von der Windows- Codeseite (1252). 8-Bit-Zeichen funktionieren möglicherweise nicht richtig. Einzelheiten finden Sie auf der psql-Handbuchseite unter »Notes for Windows users«. endor=# set lc_messages to 'sv_SE'; SET endor=# select to_char((current_date + s.a),'TMDay TMMonth ') as dates from generate_series(0,6) as s(a); dates - Donnerstag Mai 2008 Freitag Mai 2008 Samstag Mai 2008 Sonntag Mai 2008 Montag Mai 2008 Dienstag Mai 2008 Mittwoch Mai 2008 (7 Zeilen) endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'de_DE'; SET endor=# select to_char((current_date + s.a),'TMDay TMMonth ') as dates from generate_series(0,6) as s(a); dates - Donnerstag Mai 2008 Freitag Mai 2008 Samstag Mai 2008 Sonntag Mai 2008 Montag Mai 2008 Dienstag Mai 2008 Mittwoch Mai 2008 (7 Zeilen) endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'English_United_States'; SET endor=# select to_char((current_date + s.a),'TMDay TMMonth ') as dates from generate_series(0,6) as s(a); dates - Donnerstag Mai 2008 Freitag Mai 2008 Samstag Mai 2008 Sonntag Mai 2008 Montag Mai 2008 Dienstag Mai 2008 Mittwoch Mai 2008 (7 Zeilen) endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# endor=# set lc_messages to 'fr'; SET endor=# select to_char((current_date + s.a),'TMDay TMMonth ') as dates from generate_series(0,6) as s(a); dates - Donnerstag Mai 2008 Freitag Mai 2008 Samstag Mai 2008 Sonntag Mai 2008 Montag Mai 2008 Dienstag Mai 2008 Mittwoch Mai 2008 (7 Zeilen) endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Deadlock condition in driver
On Wed, 21 May 2008, Daniel Migowski wrote: I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). We already consider this case for batch execution and break the batch into an internal size that we expect is safe from deadlock. It looks like we should be doing the same for these one query batches. I'm not sure how tough that will be, but I'll take a look. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Deadlock condition in driver
Hello dear developers, I came across a deadlock condition in the JDBC driver that rises when very large queries, containing thousends of statements are send to the server with statement.execute(). I need this functionality, which work well with less than 6445 statements to send update scripts along with my application to the server. The problem is the result of filled (and unemptied) TCP-Buffers. The driver takes all statements and sends them to the server with the extended query protocol. See this log snipped, which contains the last 10 lines before the eternal halt of the test application below (repeats every 4 lines): 21:12:22.919 (1) FE=> Parse(stmt=null,query="select 0",oids={}) 21:12:22.919 (1) FE=> Bind(stmt=null,portal=null) 21:12:22.919 (1) FE=> Describe(portal=null) 21:12:22.919 (1) FE=> Execute(portal=null,limit=0) 21:12:22.919 (1) FE=> Parse(stmt=null,query="select 0",oids={}) 21:12:22.919 (1) FE=> Bind(stmt=null,portal=null) 21:12:22.919 (1) FE=> Describe(portal=null) 21:12:22.919 (1) FE=> Execute(portal=null,limit=0) 21:12:22.919 (1) FE=> Parse(stmt=null,query="select 0",oids={}) 21:12:22.919 (1) FE=> Bind(stmt=null,portal=null) Each statement sent to the server result in the following (yet still unreceived) answers send from the server to the client: 21:27:50.169 (1) <=BE CommandStatus(SELECT) 21:27:50.169 (1) <=BE ParseComplete [null] 21:27:50.169 (1) <=BE BindComplete [null] 21:27:50.169 (1) <=BE RowDescription(1) 21:27:50.169 (1) <=BE DataRow Since the driver is happy sending stuff, and the server happy answering it, after a while the clients TCP receive buffer is full, some millis later the servers TCP send buffer, some millies later the servers TCP receive buffer and then finally the client TCP send buffer. Increasing any of them delays the problem to a larger amount of statements. When piping my script to psql, or sending it by PGAdmin there is no problem. I suggest the following solution: After sending 32kb (or the current send buffer size, Socket.getSendBufferSize()), the client checks for the amount of data in the receive buffer for every statement following. If its full (which means the server might already be blocked), there are two possiblities, from which the first is my favorite, and the second the option to choose, if the first is not supported on the platform. 1. The receive buffer is increased in 32kb steps (or the current send buffer size, or even 64k, taking the servers expected receive buffer into account, to). This would unblock the server and gives enough space for more (small) responses from the server. Afterwards the receive buffer should be trimmed to its original size to don't become trapped by decreased performance from large buffers. This method might be a bit slower than the currently implemented one for cases in which the answers of 32kb of statements would fit into the existing buffers, but you don't expect lightning speed in such situations anyway, and everything is better then being deadlocked in a production system. 2. We take all data available in the receive buffer already and place it into a local byte[] to make space for more data, and release blocking on the server side this way. This option might be a bit slower than the first. A deadlock condition can yet be artificially constructed: If one sends a SELECT that sends large amounts of data from the server to the client, so the server is still not ready to process the next commands when we continue to bombard it with statements, there might still be a lock condition. But I cannot think of any use case where you have large quantities of statements like me, AND expect to receive large amounts of data which is discard anyway since there are following statements. So we can ignore this case, and happily send gig sized update scripts to the server in one call the driver :). Currently my solution is to increase the TCP buffer size in a copy of the PGStream class, which shadows the original class in the driver jar (bad style...). With best regards, Daniel Migowski - TEST APP import java.io.IOException; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.util.Properties; /** * This class demonstrates the deadlock condition in the JDBC driver. * * Author: dmigowski */ public class DeadLockDemonstration { public static void main (String args[]) throws IOException, SQLException { DriverManager.registerDriver(new org.postgresql.Driver()); Properties props = new Properties(); props.setProperty("user","ik"); props.setProperty("password","ik"); props.setProperty("loglevel","2"); Connection c = DriverManager.getConnection( "jdbc:postgresql://localhost:5434/postgres",props); StringBuilder b = new StringBuilder(); for(int i=1; i<1
Re: [BUGS] Getting the command line to work
On Wed, May 21, 2008 at 6:43 PM, Paul Jordan <[EMAIL PROTECTED]> wrote: > Hi. Perhaps this isn't the proper place to send this, but it's the only > address I have. I've installed postgres and I'm trying to use the command > prompt to create a database (PGAdmin III having failed miserably at the > task). Please define "failed miserably". pgAdmin should only ever fail if you have a problem such as lack of privileges or disk space or similar, and then should give you an appropriate error message. > The documentation I'm working with, created by people I trust know > what they're doing, says that I should enter the following: > > "createdb qf_local -U postgres -W -h localhost" Unfortunately it seems they don't know what they're doing. Try: createdb -U postgres -W -h localhost qf_local Per the docs at http://www.postgresql.org/docs/8.3/interactive/app-createdb.html -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Getting the command line to work
Hi. Perhaps this isn't the proper place to send this, but it's the only address I have. I've installed postgres and I'm trying to use the command prompt to create a database (PGAdmin III having failed miserably at the task). The documentation I'm working with, created by people I trust know what they're doing, says that I should enter the following: "createdb qf_local -U postgres -W -h localhost" But when I do that, it tells me that there are too many command line arguments and it fails. What am I doing wrong? I've never worked with DOS before, so my error might even be blindingly obvious, but I have no idea what it is. Any help you could give me in getting postgres to do what it's supposed to do would be marvelous. Many thanks, Paul Jordan Digital Archivist Occidental College
Re: [BUGS] error message "psql: expected authentication request from server, but received " when using psql to connect remote database
TIAN Justin wrote: I met an error, when psql client version is 8.1.4, I use it to connect to remote database or local database, such as "psql -U name -p -d -h ", it will prompt error message "psql: expected authentication request from server, but received ", but if the client version is 8.0.3, there is no problem, I don't know why, does it the configuration problem? Please post the exact output you're getting in both cases. What version is the server? You should upgrade to the latest minor version, which is 8.1.11 for the 8.1 series, and 8.0.15 for the 8.0 series -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] error message "psql: expected authentication request from server, but received " when using psql to connect remote database
Hi, I met an error, when psql client version is 8.1.4, I use it to connect to remote database or local database, such as "psql -U name -p -d -h ", it will prompt error message "psql: expected authentication request from server, but received ", but if the client version is 8.0.3, there is no problem, I don't know why, does it the configuration problem? Thanks Justin