Re: [BUGS] Upgrade from 7.4.5 to 8.3.3
Hmm, It does not look good. Your OS does not return proper information about codeset. Following code is broken: setlocale(LC_CTYPE, ctype); sys = nl_langinfo(CODESET); sys = strdup(sys); See http://www.opengroup.org/onlinepubs/009695399/functions/nl_langinfo.html It seems you need to fix OS first. After that we can add CODESET mapping to PostgreSQL. Zdenek Harvey, Allan AC napsal(a): Zdenek Thanks for your reply. I guess we don't have locale mapping for SCO OpenServer5.7. See http://doxygen.postgresql.org/chklocale_8c-source.html Browser Timed out. (?) Could you run following code: http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php and send output. Zdenek Output as requested: bash-2.05$ for LOCALE in `locale -a`; do locale_test $LOCALE; done C_C.C ...- NO MATCH cs_CZ.ISO8859-2 ...- NO MATCH english_uk.ISO8859-15 ...- NO MATCH english_uk.8859 ...- NO MATCH -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4493: Memory leak in informix.c
The following bug has been logged online:
Bug reference: 4493
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in informix.c
Details:
In file src/interfaces/ecpg/compatlib/informix.c:763
It seems to me that variable "temp" leaks memory here if initValue() fails:
temp = (char *) malloc(fmt_len + 1);
/* put all info about the long in a struct */
if (!temp || initValue(lng_val) == -1)
{
errno = ENOMEM;
return -1;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4494: Memory leak in pg_regress.c
The following bug has been logged online:
Bug reference: 4494
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in pg_regress.c
Details:
In file src/test/regress/pg_regress.c:1112
It seems to me that variables "s" and "tmp" leak memory here if last_dot is
false:
static char *
get_alternative_expectfile(const char *expectfile, int i)
{
char *last_dot;
int ssize = strlen(expectfile) + 2 + 1;
char *tmp = (char *) malloc(ssize);
char *s = (char *) malloc(ssize);
strcpy(tmp, expectfile);
last_dot = strrchr(tmp, '.');
if (!last_dot)
return NULL;
*last_dot = '\0';
snprintf(s, ssize, "%s_%d.%s", tmp, i, last_dot + 1);
free(tmp);
return s;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4495: Memory leak in procarray.c
The following bug has been logged online: Bug reference: 4495 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: Latest cvs Operating system: Error in source code Description:Memory leak in procarray.c Details: In file src/backend/storage/ipc/procarray.c:386 I realize (from the comments) that xids is supposed to hold memory for the whole time of the programs execution, but it seems to me that it leaks memory when program is closed. Modern operating systems should release the memory when program is closed even if the application doesn't release it, but I thought about reporting this anyway. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4496: Memory leak in pg_dump.c?
The following bug has been logged online: Bug reference: 4496 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: Latest cvs Operating system: Error in source code Description:Memory leak in pg_dump.c? Details: In file src/bin/pg_dump/pg_dump.c:3741 It seems like variables "constrinfo" and "indxinfo" leak memory e.g. at line 3741 and also on many other similar functions. If the memory is released somewhere I failed to find the location where it is released. So please either fix the leak if there is a leak or document better where the memory is released. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
