[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 port -d database -h ip, 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
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 port -d database -h ip, 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] 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] 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] 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; i10; i++ ) {
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] 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] 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 port -d database -h ip, 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
