Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1igvbI-0008Gm-D9 for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Dec 2019 19:00:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1igvbG-0004Jm-QV for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Dec 2019 19:00:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1igvbG-0004DK-IG for pgsql-bugs@lists.postgresql.org; Mon, 16 Dec 2019 19:00:10 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1igvbA-0001AR-5r for pgsql-bugs@lists.postgresql.org; Mon, 16 Dec 2019 19:00:08 +0000 Received: by mail-lf1-x135.google.com with SMTP id f15so5031687lfl.13 for ; Mon, 16 Dec 2019 11:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=uFElA3iU36t1qBj6dtcSiOemNVL8NoeupFgC9J3MugI=; b=bgmzPrh3v3ZOSq2Uat34mXTha98Yz0ElLZEYNNEoTo3M3Fed9rDfpv0cf6Ti9/Rv/A /YGmpLwvNZAqolUOnEHEt5Y5ILM4Iz9gMDqU+Y4955/vPP2mrkaGOXC1KjY5TZ6UEXQI oQ016NhCalOQu8OehLrRoipOIOgXeX8GW5YVWUBN0Af5nzW9nBTpuvHrR8nvURQwSl/Y 6teL5BS5ulOtaIIW5WoMQUKjPcgi11bfSysrqE6zte+QzqI08gM3/+ZCYQohUh3EVVwI k2U/lqFk7qPDPIQsU5ADGLKauILoury3/GfW1IMQIb3cqHXMfIWnTGq1wN7NgY1St3Py dUzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=uFElA3iU36t1qBj6dtcSiOemNVL8NoeupFgC9J3MugI=; b=O+nFbrvSaTNkXVhjYivbObeNFmCT9yTGJ3mGvp8Q6mTS8EUrC5f+xdyouWkerjiVm0 GhrZdm5fWQdj180pKV/BVoqk4UscE+f98RKPI7BvZLRC2IgId/ALlphqwY99xbRgQgJI ktkGKOYtaov4k+6YVBkdi33ew/M2FEA9YiqFTDV8E1/TSmUxuNtqQH1NRgGuJHIz1h2B 4K+CvBffoFO77lmRUpykpw1hP2/Mvpix1e7qBJU4ra790wbYWb9QkOFXSz3aib+9gOGC AWXCxl4rBIo26JFr629rw82S8mnHmISz4c4Zrx6u/fVcSPvoRX5Fk9yPNV5DwiifyN7x HmGA== X-Gm-Message-State: APjAAAW4K5h3i8qjidVjgGlDRmfpnUj86KSSZF+Z6rzul/0fIl3S7j7H 8pPpZoSzSDELFMxpbtu7p6TdcloVqmM= X-Google-Smtp-Source: APXvYqySfsPZq46vO+1D+GqnvXnksRiGc6aA7E+HklypuowMRTHkwYossmCZadNDHNLZHsKtKqWApw== X-Received: by 2002:ac2:48bc:: with SMTP id u28mr306191lfg.81.1576522802970; Mon, 16 Dec 2019 11:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.4.219]) by smtp.gmail.com with ESMTPSA id y72sm9723531lfa.12.2019.12.16.11.00.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2019 11:00:02 -0800 (PST) Subject: Re: BUG #16162: create index using gist_trgm_ops leads to panic To: Heikki Linnakangas , Jeff Janes Cc: Tomas Vondra , Tom Lane , kunert@cms.hu-berlin.de, pgsql-bugs References: <16162-45d21b7b6c1a3105@postgresql.org> <20191212125023.vpk6zbbeldzmyerc@development> <26141.1576158262@sss.pgh.pa.us> <20191213001618.jqeousv77xnlds7x@development> <2ca3ae2a-e770-012b-3da1-169a3818927a@iki.fi> <7b7e1807-7393-ad90-7492-7837d3956308@iki.fi> From: Alexander Lakhin Message-ID: <4dc09c87-c10d-801e-830b-ae82de53a4a0@gmail.com> Date: Mon, 16 Dec 2019 22:00:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <7b7e1807-7393-ad90-7492-7837d3956308@iki.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello Heikki, 16.12.2019 15:02, Heikki Linnakangas wrote: > > I added the "stack-downlinkoffnum = InvalidOffsetNumber" to the first > call on Friday. But the second call needs the same treatment, because > it's possible that we reuse the same stack on a later call to > gistfinishsplit(), if a grandchild page is split twice, for the same > leaf insert. I feel pretty dumb, because I looked at that second call > on Friday too, thinking if it also needs to reset 'downlinkoffnum', > but somehow I concluded it does not. Clearly it does, as this test > case demonstrates. > > Fix committed. Thanks again for the report! I can confirm that now the issue is gone. Thank you! Best regards, Alexander