From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Johann Spies <jspies(at)sun(dot)ac(dot)za> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: ERROR: invalid memory alloc request size |
Date: | 2007-05-17 14:40:04 |
Message-ID: | 25608.1179412804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Johann Spies <jspies(at)sun(dot)ac(dot)za> writes:
> Breakpoint 1, 0x0827eef6 in errfinish ()
> (gdb) bt
> #0 0x0827eef6 in errfinish ()
> #1 0x0828039c in elog_finish ()
> #2 0x082993b3 in MemoryContextAlloc ()
> #3 0x0828d437 in pg_mb2wchar ()
> #4 0x0811c288 in CreateCopyDestReceiver ()
> #5 0x0811ea43 in DoCopy ()
> #6 0x081f9d00 in ProcessUtility ()
> #7 0x081f6ed9 in PostgresMain ()
> #8 0x081f7cac in FreeQueryDesc ()
> #9 0x081f84d9 in PortalRun ()
> #10 0x081f3b51 in pg_parse_query ()
> #11 0x081f5296 in PostgresMain ()
> #12 0x081c8a1f in ClosePostmasterPorts ()
> #13 0x081c9924 in PostmasterMain ()
> #14 0x081823b5 in main ()
Hmmm ... this is interesting, but unfortunately backtraces from
non-debug builds are often not very trustworthy, and that seems to have
happened here. CreateCopyDestReceiver doesn't call pg_mb2wchar, and
pg_mb2wchar doesn't call MemoryContextAlloc, so we're being lied to
right at the spot where we might've hoped to learn something.
Could you please rebuild the executables with --enable-debug and try
again?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2007-05-17 15:27:15 | Re: Manual trigger removal [WAS] Flushing Postgres Function Cache |
Previous Message | Raf | 2007-05-17 14:29:37 | Re: Manual trigger removal [WAS] Flushing Postgres Function Cache |