Re: [BUGS] error message psql: expected authentication request from server, but received when using psql to connect remote database
Tom Lane, Thanks for your response, Actually, we don't directly use postgre server,we open TCP connection to support postgre wire protocol, so psql client can connect to our application, I found the problem is in the StartupMessage, when psql client version is 8.1.4, the major and minor version in StartupMessage is 1234 and 5679, not 3 and 0, that is the problem, I want to know whether it is the bug of 8.1.4, or I can do some configuration? Thanks again for your answer Thanks, Justin -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, May 22, 2008 9:43 PM To: TIAN Justin Cc: Heikki Linnakangas; 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 [EMAIL PROTECTED] writes: 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 What is in the server's pg_hba.conf file? I'm particularly wondering what auth method is being selected ... regards, tom lane -- 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] BUG #4186: set lc_messages does not work
Euler Taveira de Oliveira wrote: please observe the (previously already submitted) test queries. i've removed the date/time testqueries to no further distract from the problem. the bogus query select x; always results in a german error messages no matter what LC_MESSAGES is set: OK, that's another problem. AFAIK, that's a known problem because Windows doesn't have LC_MESSAGES. The above comment (pg_locale.c) suggests that there is no verification for the locale that is been set. A possible solution is to use IsValidLocaleName() [1] or LocaleNameToLCID() [2] but it seems that they're only available for Vista. :( Maybe we could emulate one of these functions with a mapping table [3]. [searching ...] It seems there are problems with LCIDs; they don't describe the locales acurately. pgwin hackers? how does LC_MESSAGES differ from for example LC_TIME? in LC_TIME, the checking of the specified locale seems to work: endor=# set LC_MESSAGES = 'en-US'; SET endor=# select x; FEHLER: Spalte »x« existiert nicht ZEILE 1: select x; ^ endor=# set LC_TIME = 'en-US'; FEHLER: ungültiger Wert für Parameter »lc_time«: »en-US« endor=# set LC_TIME = 'en'; FEHLER: ungültiger Wert für Parameter »lc_time«: »en« endor=# set LC_TIME = 'English'; SET maybe one could as a workaround just use the lc_time locale checks for lc_messages on windows systems? or at least match against the internal pgsql supported translations. i don't mind having to specify en instead of English if that gets me english error messages ;) Could you try to use one of the locale names described in [4]? i take it you meant link [3]. i've tried 'en-US' and others, same problem, errors in german (excerpt above). [1] http://msdn.microsoft.com/en-us/library/ms776379(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms776388(VS.85).aspx [3] http://msdn.microsoft.com/en-us/library/ms776260.aspx regards, thomas -- 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 #4187: function to_tsvector not immutable
The following bug has been logged online: Bug reference: 4187 Logged by: Martin Sullivan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Fedora Core 9 Description:function to_tsvector not immutable Details: Postgres 8.3 now supports tsearch2 as standard and it's built into the distribution. So, to_tsvector, tsvector, the '@@' operator al are readily available. The only wrinkle being that to_tsvector needs to be ALTERed to IMMUTABLE using the following (as user postgres): alter function to_tsvector(regconfig,text) immutable alter function to_tsvector(text) immutable This is needed to allow CREATE INDEX to work with these functions and the access methods GIN and GIST, else you get an error message about indexes requiring immutable functions. It should be added that the to_tsvector are declared immutable in the 8.2 contrib distribution. -- 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 #4188: Array field column (varchar[]) cannot be cast to type text
The following bug has been logged online: Bug reference: 4188 Logged by: Murali Doss Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Linux Description:Array field column (varchar[]) cannot be cast to type text Details: Dear All, I have a array field column varchar[] data type and i need to change to text data type.but it throwing following error ALTER TABLE mytable ALTER mycolumn TYPE text; ERROR: column mycolumn cannot be cast to type text SQL state: 42804 Please suggest a good solution. Regards Murali -- 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] BUG #4188: Array field column (varchar[]) cannot be cast to type text
Murali Doss wrote: I have a array field column varchar[] data type and i need to change to text data type.but it throwing following error ALTER TABLE mytable ALTER mycolumn TYPE text; ERROR: column mycolumn cannot be cast to type text SQL state: 42804 This is not a bug. Use ALTER TABLE mytable ALTER mycolumn TYPE text USING -- 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
Re: [BUGS] BUG #4187: function to_tsvector not immutable
Martin Sullivan [EMAIL PROTECTED] writes: The only wrinkle being that to_tsvector needs to be ALTERed to IMMUTABLE using the following (as user postgres): alter function to_tsvector(regconfig,text) immutable alter function to_tsvector(text) immutable The current settings are intentional: the one-parameter form of to_tsvector depends on a GUC parameter, so claiming it is immutable is simply wrong. Please read the documentation concerning how to use these functions with an index. regards, tom lane -- 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 #4190: sparc64 test suite fails
The following bug has been logged online: Bug reference: 4190 Logged by: Dennis Gilmore Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Linux Description:sparc64 test suite fails Details: errors test fails. the following is the output. which to me indicates it passed but gave different output. *** ./expected/errors.out Sat Nov 10 09:36:44 2007 --- ./results/errors.outFri May 23 09:18:27 2008 *** *** 304,312 select 1/0; ERROR: division by zero select 1::int8/0; ! ERROR: division by zero select 1/0::int8; ! ERROR: division by zero select 1::int2/0; ERROR: division by zero select 1/0::int2; --- 304,314 select 1/0; ERROR: division by zero select 1::int8/0; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero. select 1/0::int8; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero. select 1::int2/0; ERROR: division by zero select 1/0::int2; == -- 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 #4191: Include hint for Windows-like locals in documentation
The following bug has been logged online: Bug reference: 4191 Logged by: Martin Saschek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.7; 8.3.1 Operating system: Windows XP Description:Include hint for Windows-like locals in documentation Details: include a hint on the Windows-like encoding of locale settings in Chapter 21. Localization. Only by chance and after several hours (!) I found out that on Windows I should use German_Germany rather than de_DE. -- 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] BUG #4190: sparc64 test suite fails
Dennis Gilmore [EMAIL PROTECTED] writes: errors test fails. the following is the output. which to me indicates it passed but gave different output. No, it failed. The code in question looks like this: int64arg1 = PG_GETARG_INT64(0); int32arg2 = PG_GETARG_INT32(1); int64result; if (arg2 == 0) ereport(ERROR, (errcode(ERRCODE_DIVISION_BY_ZERO), errmsg(division by zero))); result = arg1 / arg2; and the output you are showing indicates that the compiler thought it could rearrange the code so that the division was executed *despite* the protective test in front of it. IMHO, what you have here is a compiler bug, or at least the gcc boys are going to need to provide a damn good excuse why it's not. BTW, kindly revert the patch you inserted in the Fedora repository. regards, tom lane -- 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] BUG #4190: sparc64 test suite fails
Tom Lane [EMAIL PROTECTED] writes: IMHO, what you have here is a compiler bug, or at least the gcc boys are going to need to provide a damn good excuse why it's not. You don't, perhaps have any of -ffast-math or these two suboptions which -ffast-math enables turned on? `-funsafe-math-optimizations' Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations. This option should never be turned on by any `-O' option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. The default is `-fno-unsafe-math-optimizations'. `-fno-trapping-math' Compile code assuming that floating-point operations cannot generate user-visible traps. These traps include division by zero, overflow, underflow, inexact result and invalid operation. This option implies `-fno-signaling-nans'. Setting this option may allow faster code if one relies on non-stop IEEE arithmetic, for example. This option should never be turned on by any `-O' option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. The default is `-ftrapping-math'. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
