Re: PostgreSQL vs SQL/XML Standards

On 2019-Mar-07, Alvaro Herrera wrote:

> On 2019-Feb-11, Chapman Flack wrote:
>
> > xmltable-xpath-result-processing-bugfix-6.patch includes a regress/expected
> > output for the no-libxml case that was left out of -5.
>
> Pushed this one, with some trivial changes: I renamed and relocated
> Pavel's function to strdup-and-free and fused the new test cases to use
> less queries for the same functionality. Naturally I had to adjust the
> expected files ... I tried to do my best but there's always a little
> something that sneaks under one's nose.

So we now have a double-free bug here or something ... Too tired right
now to do anything about it.

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grison&dt=2019-03-08%2002%3A00%3A02

================== stack trace: pgsql.build/src/test/regress/tmp_check/data/core ==================
[New LWP 20275]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `postgres: pgbuildfarm regression [local] SELECT '.
Program terminated with signal 11, Segmentation fault.
#0 0x76a32e04 in free () from /lib/arm-linux-gnueabihf/libc.so.6
#0 0x76a32e04 in free () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x76e28380 in xmlFreeNode () from /usr/lib/arm-linux-gnueabihf/libxml2.so.2
#2 0x00481f94 in xml_xmlnodetoxmltype (cur=<optimized out>, xmlerrcxt=<optimized out>) at xml.c:3751
#3 0x004823dc in XmlTableGetValue (state=0x148c370, colnum=1994818404, typid=2124685192, typmod=0, isnull=0x7ea42117) at xml.c:4540
#4 0x0026df60 in tfuncLoadRows (econtext=0x2, tstate=0x14a8578) at nodeTableFuncscan.c:489
#5 tfuncFetchRows (tstate=0x14a8578, econtext=0x2) at nodeTableFuncscan.c:318
#6 0x0026e248 in TableFuncNext (node=0x14a83e0) at nodeTableFuncscan.c:65
#7 0x0023e640 in ExecScanFetch (recheckMtd=0x23e640 <ExecScan+816>, accessMtd=0x26db1c <TableFuncRecheck>, node=0x14a83e0) at execScan.c:93
#8 ExecScan (node=0x14a83e0, accessMtd=0x26db1c <TableFuncRecheck>, recheckMtd=0x23e640 <ExecScan+816>) at execScan.c:143
#9 0x0023c638 in ExecProcNodeFirst (node=0x14a83e0) at execProcnode.c:445
#10 0x00235630 in ExecProcNode (node=0x14a83e0) at ../../../src/include/executor/executor.h:241
#11 ExecutePlan (execute_once=<optimized out>, dest=0x14b8d08, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x14a83e0, estate=0x14a82a0) at execMain.c:1643
#12 standard_ExecutorRun (queryDesc=0x142c0e0, direction=<optimized out>, count=0, execute_once=true) at execMain.c:362
#13 0x003955f4 in PortalRunSelect (portal=0x13e3f48, forward=<optimized out>, count=0, dest=<optimized out>) at pquery.c:929
#14 0x00396a0c in PortalRun (portal=0x0, count=0, isTopLevel=<optimized out>, run_once=<optimized out>, dest=0x14b8d08, altdest=0x14b8d08, completionTag=0x7ea42414 "") at pquery.c:770
#15 0x003923c8 in exec_simple_query (query_string=0x7ea42414 "") at postgres.c:1215
#16 0x00393e8c in PostgresMain (argc=<optimized out>, argv=<optimized out>, dbname=0x0, username=<optimized out>) at postgres.c:4256
#17 0x000849a8 in BackendRun (port=0x13967b8) at postmaster.c:4399
#18 BackendStartup (port=0x13967b8) at postmaster.c:4090
#19 ServerLoop () at postmaster.c:1703
#20 0x0031607c in PostmasterMain (argc=<optimized out>, argv=<optimized out>) at postmaster.c:1376
#21 0x000864d4 in main (argc=7301080, argv=0x8) at main.c:228

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services