vacuum and row type - Mailing list pgsql-hackers

Hi!

I found problem while vacuuming with composite type (version 9.0.4). It's not so 
easy to reproduce, but it's clear what happens.

CREATE TYPE mytype AS (p point, r float8);
CREATE TABLE mytable (mt mytype);
-- create opclass fir GiST
CREATE INDEX myidx ON mytable USING gist (mt);

And vacuum fails with message:
ERROR:  could not identify a comparison function for type point

I added an assert to all such error and got a backtrace: #0  0x0000000800de8fcc in kill () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800de8fcc in kill () from /lib/libc.so.7
#1  0x0000000800de7dcb in abort () from /lib/libc.so.7
#2  0x00000000007bb05f in ExceptionalCondition (conditionName=Could not find the 
frame base for "ExceptionalCondition".
) at assert.c:57
#3  0x000000000073839a in record_cmp (fcinfo=0x7fffffffcb80) at rowtypes.c:910
#4  0x0000000000739005 in btrecordcmp (fcinfo=0x7fffffffcb80)    at rowtypes.c:1236
#5  0x00000000007eb63b in myFunctionCall2 (flinfo=0x7fffffffd170,    arg1=34521714600, arg2=34521722960) at
tuplesort.c:2506
#6  0x00000000007eb598 in inlineApplySortFunction (    sortFunction=0x7fffffffd170, sk_flags=0, datum1=34521714600,
isNull1=0'\0', datum2=34521722960, isNull2=0 '\0') at tuplesort.c:2546
 
#7  0x00000000007eb50a in ApplySortFunction (sortFunction=0x7fffffffd170,    sortFlags=0, datum1=34521714600, isNull1=0
'\0',datum2=34521722960,    isNull2=0 '\0') at tuplesort.c:2565
 
#8  0x000000000055694f in compare_scalars (a=0x809a9f038, b=0x809a9f048,    arg=0x7fffffffd150) at analyze.c:2702
#9  0x00000000007fd2cc in qsort_arg (a=0x809a9f038, n=611, es=16,    cmp=0x5568e0 <compare_scalars>,
arg=0x7fffffffd150)at qsort_arg.c:129
 
#10 0x0000000000555bb6 in compute_scalar_stats (stats=0x809a06ca0,    fetchfunc=0x554920 <ind_fetch_func>,
samplerows=611,totalrows=611)    at analyze.c:2298
 
#11 0x000000000055279a in compute_index_stats (onerel=0x8011ac828,    totalrows=611, indexdata=0x8011e10e8, nindexes=1,
rows=0x809a0c038,   numrows=611, col_context=0x8011ceed8) at analyze.c:764
 
#12 0x0000000000551eb8 in do_analyze_rel (onerel=0x8011ac828,    vacstmt=0x7fffffffd880, inh=0 '\0') at analyze.c:501
#13 0x0000000000551437 in analyze_rel (relid=16483, vacstmt=0x7fffffffd880,    bstrategy=0x80117c588) at analyze.c:217
#14 0x00000000005b0b52 in vacuum (vacstmt=0x7fffffffd880, relid=16483,    do_toast=0 '\0', bstrategy=0x80117c588,
for_wraparound=0'\0',    isTopLevel=1 '\001') at vacuum.c:246
 
#15 0x0000000000674f06 in autovacuum_do_vac_analyze (tab=0x80117cf88,    bstrategy=0x80117c588) at autovacuum.c:2692
#16 0x0000000000674403 in do_autovacuum () at autovacuum.c:2262
....

So, I think, std_typanalyze() does wrong choice between compute_minimal_stats() 
and compute_scalar_stats() because row type has defined comparison function ( 
btrecordcmp() ) but searching of actual set of comparisons functions per row's 
columns occurs too late - when btrecordcmp() is already started.

I don't have in idea how to fix it without massive refactoring. std_typanalyze() 
should be a bit clever to dig possibility of comparison or 
compute_scalar_stats() should switch to compute_minimal_stats() if underlying 
functions fail with such error.

Obviously, workaround is a adding dummy comparison function for points.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/