RE: [HACKERS] pg_dump problem
От | Ansley, Michael |
---|---|
Тема | RE: [HACKERS] pg_dump problem |
Дата | |
Msg-id | 1BF7C7482189D211B03F00805F8527F748C3FE@S-NATH-EXCH2 обсуждение исходный текст |
Список | pgsql-hackers |
This looks like a place where the sprintf is being caught with too long a string. Although 487 bytes shouldn't be too long; perhaps the rest of what's in there is causing sprintf to hooch. The limit is supposed to be around 1kB. I'll try changing the fmt style string to a series of appends. It's less efficient, but may work. Thanks... MikeA -----Original Message----- From: Patrick Welche,SCC,ext.35710, To: pgsql-hackers@postgreSQL.org Sent: 00/01/07 12:56 Subject: [HACKERS] pg_dump problem % pg_dump -sv regression > foo ... -- dumping out user-defined procedural languages -- dumping out user-defined functions Segmentation fault (core dumped) #0 0x4810dc02 in vfprintf () #1 0x480c4963 in vsprintf () #2 0x48078e8a in appendPQExpBuffer (str=0x616e746f, fmt=0x3d20656d <Address 0x3d20656d out of bounds>) at pqexpbuffer.c:197 #3 0x6c732065 in ?? () % tail foo end if; return new; end; ' LANGUAGE 'plpgsql'; CREATE FUNCTION "tg_iface_biu" ( ) RETURNS opaque AS ' declare sname text; sysrec record; begin select into sysrec * from ie., it stops in mid flight, the line is select into sysrec * from system where name = new.sysname; so it seems that the PQExpBuffer may well be to full ? -s means dumpSchema(), getFuncs(), dumpFuncs(), dumpOneFunc() pg_dump.c:dumpOneFunc():2346: appendPQExpBuffer(q, " ) RETURNS %s%s AS '%s' LANGUAGE '%s';\n", (finfo[i].retset) ? " SETOF" : "", fmtId(findTypeByOid(tinfo, numTypes, finfo[i].prorettype), false), func_def, func_lang); so it cored while printing func_def ?! which is only 487 bytes long.. Rather confused.. Are any of you seeing this? Cheers, Patrick ************
В списке pgsql-hackers по дате отправления: