Re: ODBC query problem

I would suggest, if I may, following:

replace
xfrmsize = strlen(val) + 32;
to
xfrmlen = strxfrm(NULL, val, 0) + 32

due to following reasons:
1. strxfrm(NULL, val, 0) + 1 is a correct way to determine size of
transformed buffer on
Solaris and glibc2, addition of 32 bytes just an extra cushion.

2. xfrmlen = strxfrm(NULL, val, 0) + 32 combination works for me, 6 days
without crash, QAed ;)

Regards.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, July 16, 2003 2:32 PM
To: joe666(at)gnovus(dot)com
Cc: Andrew Sullivan; Maksim Likharev; Postgresql General Mail List
Subject: Re: [GENERAL] ODBC query problem

Luis =?ISO-8859-1?Q?Maga=F1a?= <joe666(at)gnovus(dot)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