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 1lZ1H0-0001lA-2K for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Apr 2021 01:03:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lZ1Gz-0007ce-12 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Apr 2021 01:03:21 +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 1lZ1Gy-0007cV-Ms for pgsql-hackers@lists.postgresql.org; Wed, 21 Apr 2021 01:03:20 +0000 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lZ1Gv-0008Oo-Ug for pgsql-hackers@postgresql.org; Wed, 21 Apr 2021 01:03:20 +0000 Received: by mail-oi1-x22b.google.com with SMTP id k25so40877006oic.4 for ; Tue, 20 Apr 2021 18:03:17 -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=rBA6qk8EixuO5wEOCSDwHQGpoUwmfl7nkGSu0pdoAQ4=; b=wH5UNennN43t24s8qRX2QW0GRJNMhK2L0neka1mk9R0ugRtRMfYaVylYYhpbS3NU37 lxHrgZCSXKwcVwhVVdpHpoH9VMqGKfq+BaWLYcsPlgxiLxcBrUbHxztX7IfOIiQiOFiR zKfxgdcTk2VF4uN3QnvkZTqolgmFjKRxyI+IKz1qVzjuSjeCjgmguevE2s8Y+IZSSX+W lsYhphn8RtgBwk/AnMTFC3MvfO25Yxwt7qBmxF5R37KprS9reFRBHa9MxX/TMo3woygn +PkNpFdbO5JHjm3LKkqpxZoW9WGO1lQ5v8VvvL6c4ctjwRWbCnAsTaIJ9O1fVjmhHPRx lqRw== 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=rBA6qk8EixuO5wEOCSDwHQGpoUwmfl7nkGSu0pdoAQ4=; b=rLVSBJ+tHpL8HCvgCu4mfvOqBpQJclKczqfgqUttQCfwxmsHwZVvrWoO658P8/8pHl Sk6XqTw5dqMJoYZzpaVaZKSYNVYxAbSczbn1reD9NkmscDmgUxOW1Gqgj/OHtTm/BfnB xlhq58D2P3/IW9L+Z0KHny9C3J/S4gP6RBOvuX1L8n0CZv8qDPlPq1mGSWmMhfGbNCjm QbgS5BpTb3TVhUnK/+t9uYPRHiFD45q1FBb955K0NddDFk7IFYz+6gSPQDrLNIjCnjcw vRZenngIGUsCWYqeIqaDHjhj/crHo8lLQ7FUQVq+G5FD8V+1FaWfbm8JAtBgp+YqIDgw 9bxw== X-Gm-Message-State: AOAM533KfnBmpLhNjw+barjRFt23LUIgrDJvpzjq+m4j6C/os3iq1bYY 7uZwu9yteO10lbzNOtWOZFlM0ozwr4QWTw== X-Google-Smtp-Source: ABdhPJzJb6FLafdHtsxzffuLBtSvmqE0dAMRedMfLTE73l1A+Fu8pNKJ3P4a2ZBQaW/nuiWD1s/tEw== X-Received: by 2002:a54:4498:: with SMTP id v24mr5084305oiv.31.1618966996138; Tue, 20 Apr 2021 18:03:16 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e30sm171410oow.11.2021.04.20.18.03.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Apr 2021 18:03:15 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id E5A7A800A3E; Tue, 20 Apr 2021 20:03:13 -0500 (CDT) Date: Tue, 20 Apr 2021 20:03:13 -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: <20210421010313.GR7256@telsasoft.com> References: <20201007230242.rnwsbnxywvthef3w@alap3.anarazel.de> <20201218235607.GC30237@telsasoft.com> <20210417021755.xdcqaqqt4y46wzt7@alap3.anarazel.de> <20210417024854.GL3315@telsasoft.com> <20210417031837.GM3315@telsasoft.com> <20210418001324.GP3315@telsasoft.com> <20210419164130.byegpfrw46mzagcu@alap3.anarazel.de> <20210420053826.GM7256@telsasoft.com> <20210420055821.GA17201@telsasoft.com> <20210421002056.gjd6rpe6toumiqd6@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210421002056.gjd6rpe6toumiqd6@alap3.anarazel.de> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Apr 20, 2021 at 05:20:56PM -0700, Andres Freund wrote: > On 2021-04-20 00:58:21 -0500, Justin Pryzby wrote: > > On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote: > > > I don't know if this is related to the other issues, but this seems leaky. > > > > And it explains how the context use counter can exceed its threshold. > > > > create or replace function fn() returns void language plpgsql as $$ declare rec int; begin SELECT relpages INTO rec FROM pg_class LIMIT 1; end $$; > Right - at the moment the context can only be recreated when there's no > JITed queries ongoing. That's why I asked whether your "real" query > contains function calls, The real query has a bunch of function calls, including aggregates and custom plpgsql functions. I reduced the whole thing to the above. ts=# explain analyze SELECT fn() FROM generate_series(1,999); ! 71692 kB max resident size ts=# explain analyze SELECT fn() FROM generate_series(1,9999); ! 332852 kB max resident size Which doesn't seem to leak if I "SELECT 1 INTO rec" instead of "SELECT relpages INTO rec". > and whether those functions are expensive enough to be JITed. The real query has: | Append (cost=44.54..192946.35 rows=79 width=741) That's a query over a 2 day period (midnight to midnight+2), so it's not hard for me to believe it sometimes exceeds 100k cost units (jit_inline_above_cost), depending on where we are in that interval, and on planner statistics. It might've been different when I first reported the problem, too. I'm not sure what you mean about expensive enough to be jited ? I think our custom functions don't have a COST set. explain analyze is showing: JIT: Functions: 201 -- Justin