Thread: pg_dump error - LOCALIZATION PROBLEM

pg_dump error - LOCALIZATION PROBLEM

From
"Erol Öz"
Date:
Hi,
I think Tom Lane is right as always. My postgresql server was configured with --enable-locale option and it works perfect with Turkish stuff. However I could not find a solution to the problem below.
Any hint?
Thanks and Regards
Erol
 
<eroloz@esg.com.tr> writes:
>> I get an error when the following command executed;
>> /usr/local/pgsql/bin/pg_dump trollandtoad > trollandtoad.out
>>
>>SET TRANSACTION command failed. Explanation from backend: 'ERROR:  Bad TRAN=
>>SACTION ISOLATION LEVEL (serializable)

>Hmm.  It would seem that strcasecmp() on your platform reports that the
>strings "SERIALIZABLE" and "serializable" are not equal.  A locale
>problem perhaps?
>
>regards, tom lane
 

Re: pg_dump error - LOCALIZATION PROBLEM

From
Peter Eisentraut
Date:
Erol Öz writes:

> I think Tom Lane is right as always. My postgresql server was
> configured with --enable-locale option and it works perfect with
> Turkish stuff. However I could not find a solution to the problem
> below.

Untested, but try this:

Edit src/backend/commands/variable.c, look for the function
parse_XactIsoLevel().  Change the code that looks like this:

        if (strcasecmp(value, "SERIALIZABLE") == 0)
                XactIsoLevel = XACT_SERIALIZABLE;
        else if (strcasecmp(value, "COMMITTED") == 0)
                XactIsoLevel = XACT_READ_COMMITTED;

into:

        if (strcmp(value, "serializable") == 0)
                XactIsoLevel = XACT_SERIALIZABLE;
        else if (strcmp(value, "committed") == 0)
                XactIsoLevel = XACT_READ_COMMITTED;

Recompile and install.

> <eroloz@esg.com.tr> writes:
> >> I get an error when the following command executed;
> >> /usr/local/pgsql/bin/pg_dump trollandtoad > trollandtoad.out
> >>
> >>SET TRANSACTION command failed. Explanation from backend: 'ERROR:  Bad TRAN=
> >>SACTION ISOLATION LEVEL (serializable)
>
> >Hmm.  It would seem that strcasecmp() on your platform reports that the
> >strings "SERIALIZABLE" and "serializable" are not equal.  A locale
> >problem perhaps?

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


Re: pg_dump error - LOCALIZATION PROBLEM

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Untested, but try this:

> Edit src/backend/commands/variable.c, look for the function
> parse_XactIsoLevel().  Change the code that looks like this:

>         if (strcasecmp(value, "SERIALIZABLE") == 0)
>                 XactIsoLevel = XACT_SERIALIZABLE;
>         else if (strcasecmp(value, "COMMITTED") == 0)
>                 XactIsoLevel = XACT_READ_COMMITTED;

> into:

>         if (strcmp(value, "serializable") == 0)
>                 XactIsoLevel = XACT_SERIALIZABLE;
>         else if (strcmp(value, "committed") == 0)
>                 XactIsoLevel = XACT_READ_COMMITTED;

Hmm.  Given that we expect the lexer to have downcased any unquoted
words, this seems like a workable solution --- where else are we using
strcasecmp() unnecessarily?

            regards, tom lane

Re: pg_dump error - LOCALIZATION PROBLEM

From
Peter Eisentraut
Date:
Tom Lane writes:

> Hmm.  Given that we expect the lexer to have downcased any unquoted
> words, this seems like a workable solution --- where else are we using
> strcasecmp() unnecessarily?

I've identified several other such places.  However, in reality we have to
consider every single strcasecmp() call suspicious.  In many places an
ASCII-only alternative is needed or the code needs to be rewritten.

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


Re: pg_dump error - LOCALIZATION PROBLEM

From
Tom Lane
Date:
>> Hmm.  Given that we expect the lexer to have downcased any unquoted
>> words, this seems like a workable solution --- where else are we using
>> strcasecmp() unnecessarily?

Wait a minute --- I spoke too quickly.  The lexer's behavior is to
downcase unquoted identifiers in a *locale sensitive* fashion --- it
uses isupper() and tolower().  We concluded that that was correct for
identifiers according to SQL99, whereas keyword matching should not be
locale-dependent.  See the comments for ScanKeywordLookup.

> I've identified several other such places.  However, in reality we have to
> consider every single strcasecmp() call suspicious.  In many places an
> ASCII-only alternative is needed or the code needs to be rewritten.

I think our problems are worse than that: once the identifier has been
through a locale-dependent case conversion we really have a problem
matching it to an ASCII string.  The only real solution may be to
require *all* keywords to be matched in the lexer, and forbid strcmp()
matching in later phases entirely.

            regards, tom lane

Re: pg_dump error - LOCALIZATION PROBLEM

From
Burak Bilen
Date:
     hi,

 I have also seen the same problem. But there is another problem related
with locale.
The function MIN is translated into mýn ( in Turkish locale support) and
postgres gives an
error message as follows:
Function 'mýn(int8)' does not exist .

  But when I use "LIKE" , postgres does the operations correctly.  I don't
know the internals of postgres,
but I want to solve this problem somehow?
 Thanks in advance.


Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Untested, but try this:
>
> > Edit src/backend/commands/variable.c, look for the function
> > parse_XactIsoLevel().  Change the code that looks like this:
>
> >         if (strcasecmp(value, "SERIALIZABLE") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcasecmp(value, "COMMITTED") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> > into:
>
> >         if (strcmp(value, "serializable") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcmp(value, "committed") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> Hmm.  Given that we expect the lexer to have downcased any unquoted
> words, this seems like a workable solution --- where else are we using
> strcasecmp() unnecessarily?
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)


Re: pg_dump error - LOCALIZATION PROBLEM

From
Burak Bilen
Date:
     hi,

 I have also seen the same problem. But there is another problem related
with locale.
The function MIN is translated into mýn ( in Turkish locale support) and
postgres gives an
error message as follows:
Function 'mýn(int8)' does not exist .

  But when I use "LIKE" , postgres does the operations correctly.  I don't
know the internals of postgres,
but I want to solve this problem somehow?
 Thanks in advance.


Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Untested, but try this:
>
> > Edit src/backend/commands/variable.c, look for the function
> > parse_XactIsoLevel().  Change the code that looks like this:
>
> >         if (strcasecmp(value, "SERIALIZABLE") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcasecmp(value, "COMMITTED") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> > into:
>
> >         if (strcmp(value, "serializable") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcmp(value, "committed") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> Hmm.  Given that we expect the lexer to have downcased any unquoted
> words, this seems like a workable solution --- where else are we using
> strcasecmp() unnecessarily?
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)


Re: pg_dump error - LOCALIZATION PROBLEM

From
Burak Bilen
Date:
     hi,

 I have also seen the same problem. But there is another problem related
with locale.
The function MIN is translated into mýn ( in Turkish locale support) and
postgres gives an
error message as follows:
Function 'mýn(int8)' does not exist .

  But when I use "LIKE" , postgres does the operations correctly.  I don't
know the internals of postgres,
but I want to solve this problem somehow?
 Thanks in advance.


Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Untested, but try this:
>
> > Edit src/backend/commands/variable.c, look for the function
> > parse_XactIsoLevel().  Change the code that looks like this:
>
> >         if (strcasecmp(value, "SERIALIZABLE") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcasecmp(value, "COMMITTED") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> > into:
>
> >         if (strcmp(value, "serializable") == 0)
> >                 XactIsoLevel = XACT_SERIALIZABLE;
> >         else if (strcmp(value, "committed") == 0)
> >                 XactIsoLevel = XACT_READ_COMMITTED;
>
> Hmm.  Given that we expect the lexer to have downcased any unquoted
> words, this seems like a workable solution --- where else are we using
> strcasecmp() unnecessarily?
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)