Thread: Something's not (de)compressing right...

When using psql's \dd command, the backend crashes with a segfault.


#0  pglz_decompress (source=0x4034aeb0, dest=0x4039e024 "") at
pg_lzcompress.c:724
724                                     *bp++ = *dp++;
#1  0x8074526 in heap_tuple_untoast_attr (attr=0x4034aeb0) at
tuptoaster.c:123
#2  0x8139a32 in pg_detoast_datum (datum=0x4034aeb0) at fmgr.c:1297
#3  0x8126d31 in text_lt (fcinfo=0xbfffec04) at varlena.c:553
#4  0x81390b0 in FunctionCall2 (flinfo=0x402bde30, arg1=1077194416,
arg2=1077171544)   at fmgr.c:722
#5  0x81413e6 in comparetup_heap (state=0x403463e0, a=0x4034ae78,
b=0x40345520)   at tuplesort.c:1719
#6  0x8140f27 in qsort_comparetup (a=0x403465e8, b=0x403465ec) at
tuplesort.c:1673
#7  0x400f2fb0 in msort_with_tmp (b=0x403465e8, n=2, s=4, cmp=0x8140f0c
<qsort_comparetup>,   t=0xbfffedcc "@'\034\b") at msort.c:58
#8  0x400f2f64 in msort_with_tmp (b=0x403465e8, n=5, s=4, cmp=0x8140f0c
<qsort_comparetup>,   t=0xbfffedcc "@'\034\b") at msort.c:49
#9  0x400f2f64 in msort_with_tmp (b=0x403465e8, n=11, s=4, cmp=0x8140f0c
<qsort_comparetup>,   t=0xbfffedcc "@'\034\b") at msort.c:49
#10 0x400f2f64 in msort_with_tmp (b=0x403465e8, n=23, s=4, cmp=0x8140f0c
<qsort_comparetup>,   t=0xbfffedcc "@'\034\b") at msort.c:49
#11 0x400f2f64 in msort_with_tmp (b=0x403465e8, n=46, s=4, cmp=0x8140f0c
<qsort_comparetup>,   t=0xbfffedcc "@'\034\b") at msort.c:49
#12 0x400f30d0 in qsort (b=0x403465e8, n=46, s=4, cmp=0x8140f0c
<qsort_comparetup>)   at msort.c:102
#13 0x813fc70 in tuplesort_performsort (state=0x403463e0) at tuplesort.c:699
#14 0x80b4385 in ExecSort (node=0x8264c10) at nodeSort.c:182
#15 0x80ad816 in ExecProcNode (node=0x8264c10, parent=0x82646c8) at execProcnode.c:296
#16 0x80b45be in ExecUnique (node=0x82646c8) at nodeUnique.c:71
#17 0x80ad81e in ExecProcNode (node=0x82646c8, parent=0x8261248) at execProcnode.c:300
#18 0x80b0aee in ExecProcAppend (node=0x8261248) at nodeAppend.c:422
#19 0x80ad7d9 in ExecProcNode (node=0x8261248, parent=0x8260f80) at execProcnode.c:260
#20 0x80b4370 in ExecSort (node=0x8260f80) at nodeSort.c:169
#21 0x80ad816 in ExecProcNode (node=0x8260f80, parent=0x8260f80) at execProcnode.c:296
#22 0x80ac7f4 in ExecutePlan (estate=0x826be70, plan=0x8260f80,
operation=CMD_SELECT,   offsetTuples=0, numberTuples=0, direction=ForwardScanDirection,
destfunc=0x402c0060)   at execMain.c:1044
#23 0x80abd88 in ExecutorRun (queryDesc=0x826be58, estate=0x826be70,
feature=3, limoffset=0x0,   limcount=0x0) at execMain.c:321
#24 0x81012f1 in ProcessQuery (parsetree=0x823a190, plan=0x8260f80,
dest=Remote)   at pquery.c:292
#25 0x8100044 in pg_exec_query_dest (   query_string=0x821a0f8 "SELECT DISTINCT a.aggname as \"Name\",
'aggregate'::text as \"Object\", d.description as \"Description\"\nFROM
pg_aggregate a, pg_description d\nWHERE a.oid = d.objoid\n\nUNION
ALL\n\nSELECT DISTINCT p.proname as"..., dest=Remote,
parse_context=0x81c28d8)   at postgres.c:665
#26 0x8100dbe in PostgresMain (argc=4, argv=0xbffff274, real_argc=3,
real_argv=0xbffffb34)   at postgres.c:1594
#27 0x80e7f62 in DoBackend (port=0x81cf8b0) at postmaster.c:1962
#28 0x80e7af1 in BackendStartup (port=0x81cf8b0) at postmaster.c:1735
#29 0x80e6e1a in ServerLoop () at postmaster.c:980
#30 0x80e68b4 in PostmasterMain (argc=3, argv=0xbffffb34) at postmaster.c:673
#31 0x80bcaf8 in main (argc=3, argv=0xbffffb34) at main.c:97


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Peter Eisentraut <peter_e@gmx.net> writes:
> When using psql's \dd command, the backend crashes with a segfault.

I get an Assert failure because heap_tuple_untoast_attr() tries to
allocate a ridiculous amount of memory.  It looks like it's being
handed a datum pointer that's pointing at plain text, not a Datum.
I don't think it's directly the untoaster's fault ... something's
dropping the ball somewhere else...
        regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> When using psql's \dd command, the backend crashes with a segfault.

The new query \dd is issuing is tickling a longstanding UNION bug.
For now I'd suggest that you work around the problem by explicitly
coercing the result of format_type() to NAME:

...
UNION ALL
SELECT DISTINCT format_type(t.oid, NULL)::name as "Name", 'type'::text as "Object", d.description as "Description"
...

The crash occurs because text_lt is used to sort a column of NAME values
--- the result of format_type is coerced to NAME so that it can be
union'd with the NAME results of the other sub-selects, but by the time
that happens we've already chosen the sort operator for the DISTINCT,
and what we chose was text_lt :-(.  If you do the coercion explicitly
then name_lt gets chosen for DISTINCT and everything works.

Actually, given that the result of format_type might well exceed 32
characters, you might think it better to coerce the results of all the
sub-selects to "text".  But the point is you can't rely on UNION's auto-
coercion to do the right thing when a sub-select requires its own sort.

I have a list of about two dozen UNION/INTERSECT/EXCEPT bugs (including
this one) that I don't think can be fixed without a querytree redesign.
So hold your nose and coerce explicitly until 7.2 ...
        regards, tom lane