Re: Gist Recovery testing

Oleg Bartunov wrote:
> On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote:
> 
>> Teodor Sigaev wrote:
>>
>>>> btree manages to avoid calling the index support functions during WAL
>>>> restore --- can't you do the same?  Perhaps you need to be including
>>>> more information in the initial xlog records, so that the cleanup step
>>>> has everything it needs.  Or resort to brute-force search (which is
>>>> more
>>>> or less what btree does).  I don't think this operation needs to be
>>>> very
>>>> efficient, since it's a corner case that should only seldom be invoked.
>>>
>>>
>>>
>>> I've just commited WALogging for GiST. It works for online backup
>>> (normal recovery) and mostly after crash, but in this case it can't
>>> restore inclompleted  inserts although it can detected and say to log
>>> thet it's needed to reindex GiST index.
>>
>>
>>
>> FYI: we now have at least 4 machines(otter,kingfisher,lionfish,corgi) on
>> the buildfarm crashing during testing of GIST-related things in contrib.
>>
>> Any chance this could be related to this change ?
> 
> 
> Most probably :) But, wait a little bit. We have a patch currently
> tested and I see no problem with all GiST-based contribs on my Slackware
> Linux 10.1 using it.


I played a little bit on lionfish(this is the result of a COPY of the
btree_gist testdata into an variant of the regressiontest tables) and
managed to get the following backtrace:


#0  gistmakedeal (state=0x0, giststate=0x7fff5128) at gist.c:597
#1  0x00436658 in gistdoinsert (r=0x2c0752e0, itup=0x100b4c10,
giststate=0x7fff5128) at gist.c:325
#2  0x00436444 in gistinsert (fcinfo=0x2b52eab0) at gist.c:288
#3  0x0073522c in FunctionCall6 (flinfo=0x2b52eab0, arg1=39, arg2=0,
arg3=810, arg4=5, arg5=39, arg6=5) at fmgr.c:1270
#4  0x0045aca8 in index_insert (indexRelation=0x2c0752e0,
values=0x7fff6920, isnull=0x7fff69a0 "", heap_t_ctid=0x100b2bec,
heapRelation=0x1, check_uniqueness=0 '\0')   at indexam.c:215
#5  0x00580074 in ExecInsertIndexTuples (slot=0x100ad710,
tupleid=0x100b2bec, estate=0x100ab5c0, is_vacuum=0 '\0') at execUtils.c:935
#6  0x00519800 in CopyFrom (rel=0x2c072a90, attnumlist=0x100ab200,
binary=0 '\0', oids=0 '\0', delim=0x7c277c "\t", null_print=0x7c2774
"\\N", csv_mode=0 '\0',   quote=0x0, escape=0x0, force_notnull_atts=0x0, header_line=0 '\0')
at copy.c:1955
#7  0x00515f08 in DoCopy (stmt=0x2b52eab0) at copy.c:1032
#8  0x00671868 in ProcessUtility (parsetree=0x10090f10, params=0x0,
dest=0x10090f78, completionTag=0x7fff6f78 "") at utility.c:608
#9  0x0066f5ec in PortalRunUtility (portal=0x100990c8, query=0x10090fc8,
dest=0x10090f78, completionTag=0x7fff6f78 "") at pquery.c:940
#10 0x0066fbb0 in PortalRunMulti (portal=0x100990c8, dest=0x10090f78,
altdest=0x10090f78, completionTag=0x7fff6f78 "") at pquery.c:1007
#11 0x0066eb30 in PortalRun (portal=0x100990c8, count=2147483647,
dest=0x10090f78, altdest=0x10090f78, completionTag=0x7fff6f78 "") at
pquery.c:617
#12 0x00666f60 in exec_simple_query (query_string=0x10090be8 "COPY
inettmp FROM STDIN") at postgres.c:1021
#13 0x0066be54 in PostgresMain (argc=4, argv=0x100513c0,
username=0x10051390 "pgbuild") at postgres.c:3186
#14 0x00621304 in BackendRun (port=0x10060300) at postmaster.c:2800
#15 0x006208bc in BackendStartup (port=0x10060300) at postmaster.c:2440
#16 0x0061d23c in ServerLoop () at postmaster.c:1221
#17 0x0061b6d0 in PostmasterMain (argc=3, argv=0x10050e40) at
postmaster.c:930
#18 0x005ab904 in main (argc=3, argv=0x10050e40) at main.c:268



Stefan