Re: ODBC query problem

I've moved all data to a new location using pg_dum/pg_restore,

Things seems to be working properly so far, data seems to be where it
should be and complete, I did the initdb once again using es_MX as
locale.

This was the first time I face such a problem with this Solaris
installation after 14 months of production time.

If anything else came up I'll let you know, thanks for the help.

On Wed, 2003-07-16 at 16:32, Tom Lane wrote:
> Luis =?ISO-8859-1?Q?Maga=F1a?= <joe666@gnovus.com> writes:
> > I've moved the database to a third location in the same disk using
> > pg_dumpall, the new location works with no errors, the initdb was made
> > without localization.
>
> > The production db was inited with es_MX locale, may that has something
> > to do with the problem ?.
>
> Yeah, according to recent reports from Maksim Likharev, there are some
> bugs in Solaris' locale libraries.  It appears that strxfrm() will
> sometimes write more bytes than it is supposed to, thereby clobbering
> nearby data structures.  The critical code is in
> src/backend/utils/adt/selfuncs.c, around line 2360 in 7.3.3:
>
>         /* Guess that transformed string is not much bigger than original */
>         xfrmsize = strlen(val) + 32;    /* arbitrary pad value here... */
>         xfrmstr = (char *) palloc(xfrmsize);
>         xfrmlen = strxfrm(xfrmstr, val, xfrmsize);
>         if (xfrmlen >= xfrmsize)
>         {
>             /* Oops, didn't make it */
>             pfree(xfrmstr);
>             xfrmstr = (char *) palloc(xfrmlen + 1);
>             xfrmlen = strxfrm(xfrmstr, val, xfrmlen + 1);
>         }
>
> We've been debating what to do to work around this bug.  I'd suggest
> changing
>         xfrmstr = (char *) palloc(xfrmsize);
> to
>         xfrmstr = (char *) palloc(xfrmsize + 32);
> so that there is more free space available than we tell strxfrm about.
> Perhaps also change
>             xfrmstr = (char *) palloc(xfrmlen + 1);
> to
>             xfrmstr = (char *) palloc(xfrmlen + 1 + 32);
> (although in theory that one should not be needed...)
>
> If that doesn't improve matters, try 100 extra bytes instead of 32.
> Please let us know how it goes.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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
--
Luis Magaña.
Gnovus Networks & Software.
www.gnovus.com