Thread: Re : Crashing v1.6.2 with a syntax error

Hello Erwin,

I am interested in the part "I get an error message with only the error code".

I have the same problem, however in the rest of your message you do have an error message with the error code
" FEHLER: Fehler »Syntaxfehler« bei »loc«   SQL state: 42601   Character: 1"

How do you achieve this ?

My problem is that, if my database is in UTF-8, I will not get any error messages, just the code.
Is that the same for you ? Have you found a solution to have an error message ?
So far we have not been able to reproduce this error: it seems its due to my PG server configuration (Ubuntu with
Frenchlocale), other configurations (including on WinXP machine) work fine. 

Cheers,
L@u
The Computing Froggy

----- Message d'origine ----
De : Erwin Brandstetter <brandstetter@falter.at>
À : pgadmin-support@postgresql.org
Envoyé le : Mercredi, 21 Février 2007, 2h06mn 21s
Objet : [pgadmin-support] Crashing v1.6.2 with a syntax error

Hi developers! Hi Dave!


Testing pgAdmin III v1.6.2 rev: 5837, client Win XP, host Debian Sarge,
PG 8.1.4. / Debian Etch, PG 8.2.1.

I have found a 'reliable' way to crash pgAdmin. Look at the following query:    select * from loc where loc like 'a%'
loc= 'b'; 
Note the syntax error: "and" is missing in the WHERE clause. If I run
this from the SQL query dialogue window I get an error message with only
the error code - but that has been reported before.
   FEHLER: Fehler »Syntaxfehler« bei »loc«   SQL state: 42601   Character: 1

However, if I open the edit grid with a filter and enter the faulty
WHERE clause, pgAdmin crashes.
I have run tests with a variety of tables and operators in PG 8.1.4 and
PG 8.2.1. Any of the following WHERE clauses triggers a crash.   fld1 like 'a%' fld2 = 'b'   fld1 = 'a%' fld2 = 'b'
fld1= 'a%' fld1 = '%a%'   ... 

The "essential" part ist the "%" at the end of the first string.


An observation I have made along the way:
Look at the error message I get from pgAdmin for the following WHERE clause:   loc = '%a' loc = ''
Note that the % is in front this time (does not trigger a crash).
   An error has occurred:   FEHLER: Fehler >>Syntaxfehler<< bei >>b<<   Line 1: EXPLAIN SELECT * FROM loc WHERE loc =
'0x1.1f9d8ap-997'loc = ''                           ^ 
The string containing the character "%" is scrambled in a weird way. The
caret in the next line points to a seemingly random position.
If I run it from psql, I get a similar error message. Only the string is
not scrambled, and the caret is in a reasonable position.
   event=# select * from loc where loc = '%a' loc = '';   FEHLER:  Fehler »Syntaxfehler« bei »loc« at character 36
ZEILE1: select * from loc where loc = '%a' loc = '';                                               ^ 
I have tried to switch the "user language" in the pgAdmin options from
English to German. To no effect.

It might have to do with locales. From my postgresql.conf:   lc_messages = 'de_AT.utf8@euro'

I have tried changing it to:   lc_messages = 'C'

After that the error message was scrambled differently:   loc = '%a' loc = ''
   An error has occurred:   ERROR: syntax error at or near "loc"   LINE 1: EXPLAIN SELECT * FROM loc WHERE loc =
'0x1.518a0fp-1002'loc  
= ''                               ^

But it crashes just as well.   loc = 'a%' loc = ''


Regards
Erwin

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate      subscribe-nomail command to
majordomo@postgresql.orgso that your      message can get through to the mailing list cleanly 






___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com

Hi Laurent!

As I stated, I get the error messages when opening the edit grid with a 
filter in pgAdmin or when running SQL from psql (standard command line 
interface of PG). In the SQL query dialogue window of pgAdmin I only get 
the error code. This problem has been reported shortly after release of 
v1.6.2 and (I think, correct me if I'm wrong) is fixed already. But we 
have to wait for the next release.

My report is concerned with the crashing, which is a more serious problem.

Regards
Erwin


laurent_roche@yahoo.com wrote:
> Hello Erwin,
>
> I am interested in the part "I get an error message with only the error code".
>
> I have the same problem, however in the rest of your message you do have an error message with the error code 
> " FEHLER: Fehler »Syntaxfehler« bei »loc«
>     SQL state: 42601
>     Character: 1"
>
> How do you achieve this ?
>
> My problem is that, if my database is in UTF-8, I will not get any error messages, just the code.
> Is that the same for you ? Have you found a solution to have an error message ?
> So far we have not been able to reproduce this error: it seems its due to my PG server configuration (Ubuntu with
Frenchlocale), other configurations (including on WinXP machine) work fine.
 
>
>  
> Cheers,
> L@u
> The Computing Froggy
>
> ----- Message d'origine ----
> De : Erwin Brandstetter <brandstetter@falter.at>
> À : pgadmin-support@postgresql.org
> Envoyé le : Mercredi, 21 Février 2007, 2h06mn 21s
> Objet : [pgadmin-support] Crashing v1.6.2 with a syntax error
>
> Hi developers! Hi Dave!
>
>
> Testing pgAdmin III v1.6.2 rev: 5837, client Win XP, host Debian Sarge, 
> PG 8.1.4. / Debian Etch, PG 8.2.1.
>
> I have found a 'reliable' way to crash pgAdmin. Look at the following query:
>      select * from loc where loc like 'a%' loc = 'b';
> Note the syntax error: "and" is missing in the WHERE clause. If I run 
> this from the SQL query dialogue window I get an error message with only 
> the error code - but that has been reported before.
>
>     FEHLER: Fehler »Syntaxfehler« bei »loc«
>     SQL state: 42601
>     Character: 1
>
> However, if I open the edit grid with a filter and enter the faulty 
> WHERE clause, pgAdmin crashes.
> I have run tests with a variety of tables and operators in PG 8.1.4 and 
> PG 8.2.1. Any of the following WHERE clauses triggers a crash.
>     fld1 like 'a%' fld2 = 'b'
>     fld1 = 'a%' fld2 = 'b'
>     fld1 = 'a%' fld1 = '%a%'
>     ...
>
> The "essential" part ist the "%" at the end of the first string.
>
>
> An observation I have made along the way:
> Look at the error message I get from pgAdmin for the following WHERE clause:
>     loc = '%a' loc = ''
> Note that the % is in front this time (does not trigger a crash).
>
>     An error has occurred:
>     FEHLER: Fehler >>Syntaxfehler<< bei >>b<<
>     Line 1: EXPLAIN SELECT * FROM loc WHERE loc = '0x1.1f9d8ap-997' loc = ''
>                             ^
> The string containing the character "%" is scrambled in a weird way. The 
> caret in the next line points to a seemingly random position.
> If I run it from psql, I get a similar error message. Only the string is 
> not scrambled, and the caret is in a reasonable position.
>
>     event=# select * from loc where loc = '%a' loc = '';
>     FEHLER:  Fehler »Syntaxfehler« bei »loc« at character 36
>     ZEILE 1: select * from loc where loc = '%a' loc = '';
>                                                 ^
> I have tried to switch the "user language" in the pgAdmin options from 
> English to German. To no effect.
>
> It might have to do with locales. From my postgresql.conf:
>     lc_messages = 'de_AT.utf8@euro'
>
> I have tried changing it to:
>     lc_messages = 'C'
>
> After that the error message was scrambled differently:
>     loc = '%a' loc = ''
>
>     An error has occurred:
>     ERROR: syntax error at or near "loc"
>     LINE 1: EXPLAIN SELECT * FROM loc WHERE loc = '0x1.518a0fp-1002' loc 
> = ''
>                                 ^
>
> But it crashes just as well.
>     loc = 'a%' loc = ''
>
>
> Regards
> Erwin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>
>
>
>
>
>     
>
>     
>         
> ___________________________________________________________________________ 
> Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
> Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
> http://fr.answers.yahoo.com
>
>   

Hi developers! Hi Laurent!

laurent_roche@yahoo.com wrote:
> Hello Erwin,
>
> I am interested in the part "I get an error message with only the error code".
>
> I have the same problem, however in the rest of your message you do have an error message with the error code 
> " FEHLER: Fehler »Syntaxfehler« bei »loc«
>     SQL state: 42601
>     Character: 1"
>
> How do you achieve this ?
>
> My problem is that, if my database is in UTF-8, I will not get any error messages, just the code.
> Is that the same for you ? Have you found a solution to have an error message ?
> So far we have not been able to reproduce this error: it seems its due to my PG server configuration (Ubuntu with
Frenchlocale), other configurations (including on WinXP machine) work fine.
 
>
> ----- Message d'origine ----
> De : Erwin Brandstetter <brandstetter@falter.at>
> À : pgadmin-support@postgresql.org
> Envoyé le : Mercredi, 21 Février 2007, 2h06mn 21s
> Objet : [pgadmin-support] Crashing v1.6.2 with a syntax error
(...)
>  Look at the following query:
>      select * from loc where loc like 'a%' loc = 'b';
> Note the syntax error: "and" is missing in the WHERE clause. If I run 
> this from the SQL query dialogue window I get an error message with only 
> the error code - but that has been reported before.
>
>     FEHLER: Fehler »Syntaxfehler« bei »loc«
>     SQL state: 42601
>     Character: 1

Laurent, I was not aware that you were the one to report the problem 
with missing error messages in the first place.
In the new Windows version Dave has compiled from SVN I still get a 
number instead of additional additional information:
(Using the faulty query from above:  select * from loc where loc like 
'a%' loc = 'b'; )
   FEHLER: Fehler »Syntaxfehler« bei »loc«   SQL state: 42601   Character: 39

Laurent, is that what you see, too?
Actually, the error message IS shown in my case. Only, I get a number 
instead of an additional line of explanation which psql would display.
That would not be by design, would it?

pgAdmin v1.4.3 only gave ponly 1 line:   FEHLER:  Fehler »Syntaxfehler« bei »loc« at character 39

psql (v8.1.8):   event=# select * from loc where loc like 'a%' loc = 'b';   FEHLER:  Fehler »Syntaxfehler« bei »loc« at
character39   ZEILE 1: select * from loc where loc like 'a%' loc = 'b';
^
 
psql (v8.2.1):   event=# select * from loc where loc like 'a%' loc = 'b';   FEHLER:  Fehler »Syntaxfehler« bei »loc«
LINE1: select * from loc where loc like 'a%' loc = 'b';                                                 ^
 
(On a sidenote: I am surprised psql gives English "LINE 1:" instead of 
"German "ZEILE 1:", as lc_messages = 'de_AT.UTF-8')

Changing the user language in the pgadmin options to German or English 
has no effect on the issue (except for changing the language, of course).



Some of my setup data (if needed):

Server 1, PG 8.1.8 on Debian Sarge:
===================================

select version();   PostgreSQL 8.1.8 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 
3.3.5 (Debian 1:3.3.5-13)

show client_encoding;   UNICODE

SELECT pg_catalog.pg_encoding_to_char(d.encoding)
FROM pg_catalog.pg_database d JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
WHERE d.datname = 'event';   UTF8
From my postgresql.conf:   datestyle = 'ISO,European'   lc_messages = 'de_AT.utf8@euro'   lc_monetary =
'de_AT.utf8@euro'  lc_numeric = 'de_AT.utf8@euro'   lc_time = 'de_AT.utf8@euro'
 
From the server OS (should be irrelevant!)   postgres@dbneu:~$ locale   LANG=de_AT.UTF-8@euro   {all LC_*
variables}="de_AT.UTF-8@euro"



Server 2, PG 8.2.3 on Debian Etch:
==================================

select version();   PostgreSQL 8.2.3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

show client_encoding;   UNICODE

SELECT pg_catalog.pg_encoding_to_char(d.encoding)
FROM pg_catalog.pg_database d JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
WHERE d.datname = 'event';   UTF8
From my postgresql.conf:   datestyle = 'iso, ymd'   lc_messages = 'de_AT.UTF-8'   lc_monetary = 'de_AT.UTF-8'
lc_numeric= 'de_AT.UTF-8'   lc_time = 'de_AT.UTF-8'
 
From the server OS (should be irrelevant!)   postgres@tester:~$ locale   LANG=de_AT.UTF-8   {all LC_*
variables}="de_AT.UTF-8"


Client: pgAdmin III v1.6.3 rev: 5941M on Win XP (SP2)
========================================


I will happily provide more data if needed.


Regards
Erwin

Hi Erwin,

Sorry for the delay in responding...

Erwin Brandstetter wrote:
> Laurent, I was not aware that you were the one to report the problem
> with missing error messages in the first place.
> In the new Windows version Dave has compiled from SVN I still get a
> number instead of additional additional information:
> (Using the faulty query from above:  select * from loc where loc like
> 'a%' loc = 'b'; )
> 
>    FEHLER: Fehler »Syntaxfehler« bei »loc«
>    SQL state: 42601
>    Character: 39
> 
> Laurent, is that what you see, too?
> Actually, the error message IS shown in my case. Only, I get a number
> instead of an additional line of explanation which psql would display.
> That would not be by design, would it?

Yes. We don't display the extra detail there because for non-fixed width
fonts the marker ends up in the wrong place. What we do instead is
display a marker in the left margin of the SQL pane to show the line
where the error occurred, and bung a squiggly underline under the error
word in the SQL pane.

We don't display it in the Edit Grid filter validation error message
because it doesn't make sense when the message refers to a full query of
which you've only written the where clause.

I am interested to know if you've managed to reproduce Laurent's problem
though, in which *only* the error number is shown in the Query Tool, and
no text at all.

Regards, Dave

Hi Dave!

dpage@postgresql.org wrote:
> Yes. We don't display the extra detail there because for non-fixed width
> fonts the marker ends up in the wrong place. What we do instead is
> display a marker in the left margin of the SQL pane to show the line
> where the error occurred, and bung a squiggly underline under the error
> word in the SQL pane.

Makes sense.

> We don't display it in the Edit Grid filter validation error message
> because it doesn't make sense when the message refers to a full query of
> which you've only written the where clause.

You have changed that only recently to while fixing the crash, right? 
Anyway, makes sense, too.

> I am interested to know if you've managed to reproduce Laurent's problem
> though, in which *only* the error number is shown in the Query Tool, and
> no text at all.

No, I have not seen that.


Regards
Erwin

Erwin Brandstetter wrote:
> Hi Dave!
> 
>> We don't display it in the Edit Grid filter validation error message
>> because it doesn't make sense when the message refers to a full query of
>> which you've only written the where clause.
> 
> You have changed that only recently to while fixing the crash, right? 

In one particular case, yes.

> Anyway, makes sense, too.
> 
>> I am interested to know if you've managed to reproduce Laurent's problem
>> though, in which *only* the error number is shown in the Query Tool, and
>> no text at all.
> 
> No, I have not seen that.

OK, thanks.

Regards, Dave

Hi Albin!

Most interesting, especially as your setup looks much like mine. And I 
do see error messages.
cc-ing Dave and Laurent as they might take special interest in your 
case. So I keep it in English.

Some more information might be useful:
encoding of the database?    -- \l command in psql or select the 
database node in pgAdmin and read from the SQL pane.
client_encoding?    -- show client_encoding;
"German as default language" in pgAdmin? Or in postgresql (-> 
postgresql.conf)?
Way of connecting? Via TCP/IP to port 5432 or some other method?
And maybe the setting in your postgresql.conf might be of interest.

BTW, backports.org has updated to postgresql 8.1.8 a couple of days ago. 
You may want to apt-get update & upgrade ..


Regards
Erwin


albin.blaschka@raumberg-gumpenstein.at wrote:
> Erwin Brandstetter wrote:
>
>> dpage@postgresql.org wrote:
>
>>> I am interested to know if you've managed to reproduce Laurent's 
>>> problem
>>> though, in which *only* the error number is shown in the Query Tool, 
>>> and
>>> no text at all.
>>
>> No, I have not seen that.
>
> Hello,
>
> I have this problem with not showing the text message, just the number...
> pgAdmin 1.6.2 (Jan 6 2007, rev: 5837; German as default language), 
> WinXP SP2
> PostgreSQL running remotely on Debian Sarge, 8.1.4 from the 
> "Backports-Repository"

Erwin Brandstetter schrieb:
> Hi Albin!
>
> Most interesting, especially as your setup looks much like mine. And I 
> do see error messages.
> cc-ing Dave and Laurent as they might take special interest in your 
> case. So I keep it in English.
>
> Some more information might be useful:
> encoding of the database?    -- \l command in psql or select the 
> database node in pgAdmin and read from the SQL pane.
> client_encoding?    -- show client_encoding;
> "German as default language" in pgAdmin? Or in postgresql (-> 
> postgresql.conf)?
> Way of connecting? Via TCP/IP to port 5432 or some other method?
> And maybe the setting in your postgresql.conf might be of interest.
>
> BTW, backports.org has updated to postgresql 8.1.8 a couple of days 
> ago. You may want to apt-get update & upgrade ..
>
>
> Regards
> Erwin
>
Hello!

Thank you for your answer - I will stick with english, too and try to 
stay on list... ;-)

As now the weekend started :-) and the setup in question is for work and 
this work is now about 130 km away with no possibility to login 
remotely, here only some answers as a first step...
As far as I remember, with pgAdmin 1.6.0 I had full error messages...
The encoding of the database seems not to matter: I have some in Latin-9 
and one in UTF-8, but there is no difference.
"German as the default language" is meant to be for pgAdmin, on the 
server I have the german/austrian locale as default.
The connection goes via TCP/IP, Port 5432, plain (no ssh)...
Details of the server I have to look up, but only on monday...

Thanks for the tip for the update of the backports!

Good night,
Albin

-- 
****************************************************************************** 

** Albin Blaschka, Mag. rer. nat.
** SURE -  Successful Restoration and Rehabilitation
**         Accompanying Infrastructural Interventions
** HBLFA Raumberg - Gumpenstein
** Abteilung für Vegetationsmanagement im Alpenraum
** Tel.: ++43 (0)3682 / 22451 - 347
** For the creation of this message 100% recycled electrons were used!
******************************************************************************* 

Erwin Brandstetter wrote:
> Hi Albin!
> 
> Most interesting, especially as your setup looks much like mine. And I 
> do see error messages.
> cc-ing Dave and Laurent as they might take special interest in your 
> case. So I keep it in English.
> 
> Some more information might be useful:
> encoding of the database?    -- \l command in psql or select the 
> database node in pgAdmin and read from the SQL pane.
> client_encoding?    -- show client_encoding;
> "German as default language" in pgAdmin? Or in postgresql (-> 
> postgresql.conf)?
> Way of connecting? Via TCP/IP to port 5432 or some other method?
> And maybe the setting in your postgresql.conf might be of interest.
> 

Hello,

In opposite I had said before it seems that it depends on the encoding 
of the database  - if the database is encoded in UTF-8, I get no 
messages, in Latin-9 I *do*...
So it seems that indeed Laurent and me have the same problem...

greetings, Albin

-- 
************************************************************************
** Albin Blaschka, Mag. rer. nat.
** SURE -  Successful Restoration and Rehabilitation
**         Accompanying Infrastructural Interventions
** HBLFA Raumberg - Gumpenstein
** Abteilung für Vegetationsmanagement im Alpenraum
** Tel.: ++43 (0)3682 / 22451 - 347
** For the creation of this message 100% recycled electrons were used!
************************************************************************

Albin Blaschka wrote:

> Hello,
> 
> In opposite I had said before it seems that it depends on the encoding 
> of the database  - if the database is encoded in UTF-8, I get no 
> messages, in Latin-9 I *do*...
> So it seems that indeed Laurent and me have the same problem...

I assume whatever script you are running doesn't change the client encoding?

What happens if you do

SET client_encoding='utf-8'

before your query?


Regards, Dave

Dave Page wrote:
> Albin Blaschka wrote:
>> In opposite I had said before it seems that it depends on the encoding 
>> of the database  - if the database is encoded in UTF-8, I get no 
>> messages, in Latin-9 I *do*...
>> So it seems that indeed Laurent and me have the same problem...
> 
> I assume whatever script you are running doesn't change the client 
> encoding?
> What happens if you do
> 
> SET client_encoding='utf-8'
> 
> before your query?
> 

Hello,

If I am connected to a database encoded in Latin-9 and I execute 
something like:

SET client_encoding='utf-8';
select * from bla

(where "bla" is obviously non existant)

I get the error nuber *and* the message, like:

FEHLER: Relation »bla« existiert nicht
SQL Status:42P01

If I am connected to a database encoded in UTF-8, I get only the error code:

select * from bla
             <--- empty line
FEHLER:
SQL Status:42P01

What is interesting: In the output/messages pane, the first line is 
empty/blank, instead of the error text (see above), if I execute again 
with an UTF-8 encoded database:

SET client_encoding='LATIN-9';
select * from bla

I do not get a message either, just the code, but the empty line 
*disappears*, the first line is "FEHLER:" (meaning Error)

I hope, my description is understandable...

Thanks a lot,
Albin

-- 
************************************************************************
** Albin Blaschka, Mag. rer. nat.
** SURE -  Successful Restoration and Rehabilitation
**         Accompanying Infrastructural Interventions
** HBLFA Raumberg - Gumpenstein
** Abteilung für Vegetationsmanagement im Alpenraum
** Tel.: ++43 (0)3682 / 22451 - 347
** For the creation of this message 100% recycled electrons were used!
************************************************************************