I wrote:
> Just to make things even more mysterious, prairiedog finally showed
> the Assert failure on its fourth run with c477f3e449 included:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2019-10-04%2012%3A35%3A41
> It's also now apparent that lapwing and locust were failing only
> sometimes, as well. I totally don't understand why that failure
> would've been only partially reproducible. Maybe we should dig
> a bit harder, rather than just deciding that we fixed it.
I did that digging, reproducing the problem on florican's host
(again intermittently). Here's a stack trace from the spot where
we sometimes downsize a large chunk:
#5 0x0851c70a in AllocSetRealloc (context=0x31b35000, pointer=0x319e5020,
size=1224) at aset.c:1158
#6 0x085232eb in repalloc (pointer=0x319e5020, size=1224) at mcxt.c:1082
#7 0x31b69591 in resize_intArrayType (num=300, a=0x319e5020)
at _int_tool.c:268
#8 resize_intArrayType (a=0x319e5020, num=300) at _int_tool.c:250
#9 0x31b6995d in _int_unique (r=0x319e5020) at _int_tool.c:329
#10 0x31b66a00 in g_int_union (fcinfo=0xffbfcc5c) at _int_gist.c:146
#11 0x084ff9c4 in FunctionCall2Coll (flinfo=0x319e2bb4, collation=100,
arg1=834250780, arg2=4290759884) at fmgr.c:1162
#12 0x080db3a3 in gistMakeUnionItVec (giststate=0x319e2820, itvec=0x31bae4a4,
len=15, attr=0xffbfce5c, isnull=0xffbfcedc) at gistutil.c:204
#13 0x080e410d in gistunionsubkeyvec (giststate=giststate@entry=0x319e2820,
itvec=itvec@entry=0x31bb5ed4, gsvp=gsvp@entry=0xffbfcd4c) at gistsplit.c:64
#14 0x080e416f in gistunionsubkey (giststate=giststate@entry=0x319e2820,
itvec=itvec@entry=0x31bb5ed4, spl=spl@entry=0xffbfce3c) at gistsplit.c:91
#15 0x080e4456 in gistSplitByKey (r=<optimized out>, page=<optimized out>,
itup=<optimized out>, len=<optimized out>, giststate=<optimized out>,
v=<optimized out>, attno=<optimized out>) at gistsplit.c:689
#16 0x080d8797 in gistSplit (r=0x31bbb424, page=0x297e0b80 "",
itup=0x31bb5ed4, len=16, giststate=0x319e2820) at gist.c:1432
#17 0x080d8d9c in gistplacetopage (rel=<optimized out>,
freespace=<optimized out>, giststate=<optimized out>,
buffer=<optimized out>, itup=<optimized out>, ntup=<optimized out>,
oldoffnum=<optimized out>, newblkno=<optimized out>,
leftchildbuf=<optimized out>, splitinfo=<optimized out>,
markfollowright=<optimized out>, heapRel=<optimized out>,
is_build=<optimized out>) at gist.c:299
So the potential downsize is expected, triggered by _int_unique
being able to remove some duplicate entries from a GIST union key.
AFAICT the fact that it happens only intermittently must boil down
to the randomized insertion choices that gistchoose() sometimes makes.
In short: nothing to see here, move along.
regards, tom lane
