Re: ODBC query problem

Поиск
Список
Период
Сортировка
От Maksim Likharev
Тема Re: ODBC query problem
Дата
Msg-id 56510AAEF435D240958D1CE8C6B1770A016D2DB9@mailc03.aurigin.com
обсуждение исходный текст
Ответ на ODBC query problem  (Luis Magaña <joe666@gnovus.com>)
Ответы Re: ODBC query problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
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@sss.pgh.pa.us]
Sent: Wednesday, July 16, 2003 2:32 PM
To: joe666@gnovus.com
Cc: Andrew Sullivan; Maksim Likharev; Postgresql General Mail List
Subject: Re: [GENERAL] ODBC query problem


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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: dump_all/restore times?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: changing an update via rules - caught in recursion