From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Jeff Davis <pgsql@j-davis.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Soumyadeep Chakraborty <sochakraborty@pivotal.io>,
        Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>, soumyadeep2007@gmail.com
Subject: Re: Memory Accounting
In-reply-to: <13773.1570203696@sss.pgh.pa.us>
References: 
 <CADwEdor2jZitB2P94on2LUAhdi0iRHv2WNseV3LJmJPenuuNpw@mail.gmail.com>
 <67f66d2fa39e35aef90093c74531a38dcd5c0f73.camel@j-davis.com>
 <CAAKRu_b2Qxr=GzE7thk8_=JDgYRnOssYBuqWdZ39R2+Heo=oQw@mail.gmail.com>
 <20190926192244.mk5ru6nkofo7am3h@development>
 <57780817877d4b40106b248b63261e21a7a56261.camel@j-davis.com>
 <20190928221249.mo2jrtlakingnc5e@development>
 <20190928222206.thidzeygazl7axhg@development>
 <392e034c1b674a1a58c217dc440ea6197081ccfa.camel@j-davis.com>
 <20191001021114.iimd77xgnstaww7j@development>
 <15151.1570163761@sss.pgh.pa.us>
 <20191004082644.wytixiukkm6ditlu@development>
 <13773.1570203696@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 04 Oct 2019 11:41:36 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8787.1570214262.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 04 Oct 2019 14:37:42 -0400
Message-ID: <8788.1570214262@sss.pgh.pa.us>
Precedence: bulk

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=3Dprairiedog&dt=3D=
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=3D0x31b35000, pointer=3D0x319e5=
020, =

    size=3D1224) at aset.c:1158
#6  0x085232eb in repalloc (pointer=3D0x319e5020, size=3D1224) at mcxt.c:1=
082
#7  0x31b69591 in resize_intArrayType (num=3D300, a=3D0x319e5020)
    at _int_tool.c:268
#8  resize_intArrayType (a=3D0x319e5020, num=3D300) at _int_tool.c:250
#9  0x31b6995d in _int_unique (r=3D0x319e5020) at _int_tool.c:329
#10 0x31b66a00 in g_int_union (fcinfo=3D0xffbfcc5c) at _int_gist.c:146
#11 0x084ff9c4 in FunctionCall2Coll (flinfo=3D0x319e2bb4, collation=3D100,=
 =

    arg1=3D834250780, arg2=3D4290759884) at fmgr.c:1162
#12 0x080db3a3 in gistMakeUnionItVec (giststate=3D0x319e2820, itvec=3D0x31=
bae4a4, =

    len=3D15, attr=3D0xffbfce5c, isnull=3D0xffbfcedc) at gistutil.c:204
#13 0x080e410d in gistunionsubkeyvec (giststate=3Dgiststate@entry=3D0x319e=
2820, =

    itvec=3Ditvec@entry=3D0x31bb5ed4, gsvp=3Dgsvp@entry=3D0xffbfcd4c) at g=
istsplit.c:64
#14 0x080e416f in gistunionsubkey (giststate=3Dgiststate@entry=3D0x319e282=
0, =

    itvec=3Ditvec@entry=3D0x31bb5ed4, spl=3Dspl@entry=3D0xffbfce3c) at gis=
tsplit.c:91
#15 0x080e4456 in gistSplitByKey (r=3D<optimized out>, page=3D<optimized o=
ut>, =

    itup=3D<optimized out>, len=3D<optimized out>, giststate=3D<optimized =
out>, =

    v=3D<optimized out>, attno=3D<optimized out>) at gistsplit.c:689
#16 0x080d8797 in gistSplit (r=3D0x31bbb424, page=3D0x297e0b80 "", =

    itup=3D0x31bb5ed4, len=3D16, giststate=3D0x319e2820) at gist.c:1432
#17 0x080d8d9c in gistplacetopage (rel=3D<optimized out>, =

    freespace=3D<optimized out>, giststate=3D<optimized out>, =

    buffer=3D<optimized out>, itup=3D<optimized out>, ntup=3D<optimized ou=
t>, =

    oldoffnum=3D<optimized out>, newblkno=3D<optimized out>, =

    leftchildbuf=3D<optimized out>, splitinfo=3D<optimized out>, =

    markfollowright=3D<optimized out>, heapRel=3D<optimized out>, =

    is_build=3D<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