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