From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sokolov Yura <funny(dot)falcon(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: BUG #3860: xpath crashes backend when is querying xmlagg result |
Date: | 2008-01-09 22:42:19 |
Message-ID: | 20080109224219.GA22548@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
Tom Lane escribió:
> We might be able to compromise by only resetting the context after
> an error, but this is still only possible if we have a way to make
> libxml let go of *all* pointers to alloc'd objects. I don't understand
> your comment that xmlCleanupParser solves it --- we call that already,
> and it doesn't seem to be preventing the problem.
We call it *after* the context has been reset -- or at least that's what
gdb is showing me.
Hardware watchpoint 3: handlers[0]
Old value = (xmlCharEncodingHandlerPtr) 0xc43580
New value = (xmlCharEncodingHandlerPtr) 0x7f7f7f7f7f7f7f7f
0x00002b579ad84283 in memset () from /lib/libc.so.6
(gdb) bt
#0 0x00002b579ad84283 in memset () from /lib/libc.so.6
#1 0x0000000000768b69 in AllocSetReset (context=0xc1d970)
at /pgsql/source/00head/src/backend/utils/mmgr/aset.c:456
#2 0x0000000000769f42 in MemoryContextReset (context=0xc1d970)
at /pgsql/source/00head/src/backend/utils/mmgr/mcxt.c:130
#3 0x000000000059791c in ReScanExprContext (econtext=0xc42050)
at /pgsql/source/00head/src/backend/executor/execUtils.c:447
#4 0x00000000005a6ed8 in ValuesNext (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/nodeValuesscan.c:106
#5 0x00000000005957ec in ExecScan (node=0xc41f38,
accessMtd=0x5a6d98 <ValuesNext>)
at /pgsql/source/00head/src/backend/executor/execScan.c:68
#6 0x00000000005a706c in ExecValuesScan (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/nodeValuesscan.c:173
#7 0x000000000058b6bd in ExecProcNode (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/execProcnode.c:360
#8 0x000000000059b86b in agg_retrieve_direct (aggstate=0xc41448)
at /pgsql/source/00head/src/backend/executor/nodeAgg.c:921
#9 0x000000000059b6d0 in ExecAgg (node=0xc41448)
at /pgsql/source/00head/src/backend/executor/nodeAgg.c:816
#10 0x000000000058b73b in ExecProcNode (node=0xc41448)
at /pgsql/source/00head/src/backend/executor/execProcnode.c:394
#11 0x0000000000588e50 in ExecutePlan (estate=0xc40f18, planstate=0xc41448,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0xc31748) at /pgsql/source/00head/src/backend/executor/execMain.c:1233
#12 0x000000000058760a in ExecutorRun (queryDesc=0xc09f78,
direction=ForwardScanDirection, count=0)
at /pgsql/source/00head/src/backend/executor/execMain.c:267
#13 0x000000000066715b in PortalRunSelect (portal=0xc382f8, forward=1 '\001',
count=0, dest=0xc31748) at /pgsql/source/00head/src/backend/tcop/pquery.c:943
#14 0x0000000000666dab in PortalRun (portal=0xc382f8, count=9223372036854775807,
isTopLevel=1 '\001', dest=0xc31748, altdest=0xc31748,
completionTag=0x7fff10f94cf0 "")
at /pgsql/source/00head/src/backend/tcop/pquery.c:769
#15 0x000000000066125f in exec_simple_query (
query_string=0xbf4938 "select xpath('any_non_empty_expression', xmlagg(el) ) as el\nfrom ( values\n ( xmlelement(name b, 0) ),\n ( xmlelement(name c, 0.1) )\n) as t(el);") at /pgsql/source/00head/src/backend/tcop/postgres.c:963
[...]
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-09 23:01:42 | Re: BUG #3860: xpath crashes backend when is querying xmlagg result |
Previous Message | Andrew Gilligan | 2008-01-09 22:37:57 | BUG #3866: Segfault during table update when using convert_from() |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-09 23:01:42 | Re: BUG #3860: xpath crashes backend when is querying xmlagg result |
Previous Message | Tom Lane | 2008-01-09 19:54:55 | Re: OUTER JOIN performance regression remains in 8.3beta4 |