Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kOqzN-0007Sm-U5 for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Oct 2020 23:30:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kOqzM-0004ti-It for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Oct 2020 23:30:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kOqzM-0004tG-7K for pgsql-hackers@lists.postgresql.org; Sat, 03 Oct 2020 23:30:52 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kOqzK-0003u5-05 for pgsql-hackers@postgresql.org; Sat, 03 Oct 2020 23:30:51 +0000 Received: by mail-io1-xd2a.google.com with SMTP id 67so2188354iob.8 for ; Sat, 03 Oct 2020 16:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=sAqjMnYrEF0q/jElmLVpFkIDbwQXo0gKuKQTRSsjO+Q=; b=v3KSq3Acj05z/u+pPmffifsJh83lFrAPBgDCx1UWzu8JvVddzNao+n5735/ExCSPr0 /oHzOchyFqJgXWV+t/Wf/dmzt9/tUW1xWJyhpnsYUW9G00nvFMp8hZI8bAhUbk+vQ5mv zyypik/ZTwhjAMcPlQQPnNDuoB332GYb/jcDUNOEn1USm5DHw43yNtBS9MHFFtJ9dUQm iSECU1/7uEXzLF98vU82gGtSWZOa9mCWD5hXnIjwAAk9+mpLWzJ4f/3Tbb7UafYr5pxc 2SHRyxZ0WK83I6fSD3O2GnBm+TB1KQ5bvHBwDJQDwHrhEqL8j9CqHO5Pc6jwaLi+Y3Ig 6Q1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sAqjMnYrEF0q/jElmLVpFkIDbwQXo0gKuKQTRSsjO+Q=; b=jHOI1fHte1I5dLKBwHUQ0elSNQGzk+OJ37Vg27vNBoxztWE/APLpfNf6GfZibzU5BS j+hlm5I2QKe4iaHEvg3qh7N4nEDzL6UV/uAR+GDfPRZuSic+SUjHwp1+UFoqynPE2EnW s9/v05pXiG9YasycZdozyzBDf5LQ99V1Xj0qAHBi1Cbs2Sm1nDFSkuqByTktIpBbxSTk 7/wKbaftI+okkRGmEFy8pnjxSpJpPHDbWl7d8lxO9StQGKWI3dhyCCrJ3cKFSKhOhtys Nuv/6JBAtAn6O+fj8731qu3QUBJtOF6U0CouNv9vg2R9qXhKjgcRj6hh34UlnHaxyIsQ /fEg== X-Gm-Message-State: AOAM530K8qYdulQroGjmht810geWHHbv/CLCcl5rJd5+/dN00zjhAHDa mNKcaRd3HjV5ASHYtzyA+tyDZA== X-Google-Smtp-Source: ABdhPJzzIwh/vBJeq1kaTaYGWtsN/Cp+l4kNLu2uFYXEn261Fkgx/IohaExsk7U9x4303XHr9mvCbQ== X-Received: by 2002:a05:6638:13c4:: with SMTP id i4mr7941159jaj.85.1601767847933; Sat, 03 Oct 2020 16:30:47 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id z15sm3362077ilb.73.2020.10.03.16.30.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Oct 2020 16:30:47 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 3214A80071F; Sat, 3 Oct 2020 18:30:46 -0500 (CDT) Date: Sat, 3 Oct 2020 18:30:46 -0500 From: Justin Pryzby To: Andres Freund Cc: pgsql-hackers@postgresql.org, Tom Lane Subject: Re: terminate called after throwing an instance of 'std::bad_alloc' Message-ID: <20201003233045.GM8476@telsasoft.com> References: <20201001021609.GC8476@telsasoft.com> <20201003220236.GL8476@telsasoft.com> <20201003230149.mtd7fjsjwgii3jv7@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201003230149.mtd7fjsjwgii3jv7@alap3.anarazel.de> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote: > The below turned out to be somewhat obsoleted by what you wrote below, > which I unfortunately hadn't yet read - but I think it's still good > information, so I'm not gonna delete it: Right, I understand that RES RAM might includes shared buffers and demand loaded file-backed and mmap stuff. But on our servers, I tentatively wouldn't expect it to be more than a handful of GB. It might be true that most of our report processes run in a forked children, specifically to avoid leaks, and the forked children would have their own, shortlived backend, which would hide any postgres leak (in addition to having tried to use jit since v11). > > I was able to make a small, apparent leak like so. This applies to > > postgis3.0/postgres12/LLVM5/centos7, and > > postgis3.1alpha/postgres13/LLVM9/centos8. > > > > Inlining is essential to see the leak, optimization is not. Showing every 9th > > query: > > > > $ for a in `seq 1 99`; do echo "SET jit_inline_above_cost=1; SET jit_optimize_above_cost=-1; SET jit_above_cost=0; SET jit_expressions=on; SET log_executor_stats=on; SET client_min_messages=debug; SET jit=on; explain analyze SELECT st_x(site_geo) FROM sites WHERE site_geo IS NOT NULL;"; done |psql ts 2>&1 |grep 'resident' |sed -n '1~9p' > > ! 46024 kB max resident size > > ! 46492 kB max resident size > > Huh, that's certainly not good. Looking. Reproduce like: postgres=# CREATE EXTENSION postgis; postgres=# CREATE TABLE geo(g geometry(point)); postgres=# INSERT INTO geo SELECT st_GeometryFromText('POINT(11 12)',0) FROM generate_series(1,99999); postgres=# SET jit_above_cost=0; SET jit_inline_above_cost=0; SET client_min_messages=debug; SET log_executor_stats=on; explain analyze SELECT st_x(g) FROM geo;