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 1hO1V5-0006mz-Gr for pgsql-bugs@arkaria.postgresql.org; Tue, 07 May 2019 14:55:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hO1V4-0001GG-9L for pgsql-bugs@arkaria.postgresql.org; Tue, 07 May 2019 14:55:22 +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 1hO1V3-0001Cd-SJ for pgsql-bugs@lists.postgresql.org; Tue, 07 May 2019 14:55:22 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hO1Uz-0000xo-Fu for pgsql-bugs@lists.postgresql.org; Tue, 07 May 2019 14:55:20 +0000 Received: by mail-qt1-x843.google.com with SMTP id r3so9459578qtp.10 for ; Tue, 07 May 2019 07:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Qa5h8FoXY7Nb8bTnnVSW/3CVbSv8/tR+7SEHPpAD9T0=; b=f/VYIbNmTT2I7nmfcgyDTA7TCdUHUEdYQlqhk+BTG48/+nlYaAE4jQ9X1hrBo3ba6X /fbciq0sGCc7QDvN3d8ewZ/FmeWzbNisxjfoeGO/MXaFaHQMLRzI/z6rR7+U3DAUV8X1 JrJ/6sqKZhmvyPbzw06T7cb55R79GJNt1zMItM2zHuoh4vpQqXLAB+NfITPNaU1vUB1Y 5s6Euu84YnyST2J1MuCMFT3JsIPGrpDP/UX0Sm/9fk28JYMBfdCcm31TVAC8FL4dCf2L P2blcaU86ia7X6hDdEkHMJFMzxFMwE/UID3ThYlUl+dLeqgukT0xMHMmVBK8n55AH59H KfRA== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Qa5h8FoXY7Nb8bTnnVSW/3CVbSv8/tR+7SEHPpAD9T0=; b=SW34VohfGqfnZkI56DjVU0Z3/w6t4a4knejRR23Olx4H65EMtYD72O7hd/9r2km7F3 N+18HBalrwr+OgNO4BjNFZR3c/5D80GKPGelSYdOFMjOIbwLf3bU5LVG8p1Pn0lpYTmS QT6CJXTTO/d+kIt7waVeyGCCF/dXQg9yAOCnVR8eGrXMgMU3QsKhtYn79VK2tD6bvFkr Z3/yuG7VDT6gVUcxtuB2PTaXCfuvdc7JH7T0MQTYMWZEUD1sbNDMW8KTeQcy1olGR8Ai eACU3vfx3l3zu9rAVBKX6GYLu6E1rCllaXe5yO/iGiX6fk4Qhqi+NvU4jAGb8d1nhzn1 LA4A== X-Gm-Message-State: APjAAAXg5d7zIppLOlQGbvEY5MiUo0m/1FsUGUEk7QQmn3KIBXvYE8Dk lddJB5//LftFPRQZeTeRnb4SOb5tbcNecLgsF7+hzcFnEG3VpXn6pW0ApLJFePiKtEw/XH3AAjj wHGDy8Z5knAZHeP2Ep1kEljJQUXwRvzKnC2TcykUMwy1cPxG4yDuDhV4gzfYJm3LyhyoFtQxg3Z W3j+KUmkkvJQ== X-Google-Smtp-Source: APXvYqyGDmMMgJyoAuN+KIzUMrUrq4JUrwDOgUL/EYfBtEvaMYrQGbdVWOhifBQSBNquglI9TtQ/wA== X-Received: by 2002:ac8:611b:: with SMTP id a27mr28335544qtm.14.1557240915472; Tue, 07 May 2019 07:55:15 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id j93sm7451473qte.42.2019.05.07.07.55.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 May 2019 07:55:15 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 136F1120DC8; Tue, 7 May 2019 10:55:13 -0400 (-04) Date: Tue, 7 May 2019 10:55:13 -0400 From: Alvaro Herrera To: Euler Taveira Cc: James Tomson , pgsql-bugs@lists.postgresql.org, Eric Jensen Subject: Re: invalid memory alloc request size from pg_stat_activity? Message-ID: <20190507145513.GA7111@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-May-07, Euler Taveira wrote: > Em seg, 6 de mai de 2019 ąs 20:04, James Tomson escreveu: > > > > ourdb=> SELECT pid, state, age(query_start, clock_timestamp()), usename, query FROM pg_stat_activity WHERE query != '' AND state != 'idle' ORDER BY age limit 100; > > ERROR: invalid memory alloc request size 1652113408 > > > That is because it is limited to 1GB - 1. > > > Maybe this has to do with us setting track_activity_query_size=102400? Is there a known safe maximum for that, or could there be some other problem? > > > Question is: why do you want to return such a big query text? That's > impractical for admin/monitoring tools. We can usually identify a > query with 1024 bytes (that is the default). Hmm, but 102400 is only 100kB, nowhere near the 1GB-1 limit, so there's something odd going on there. I would start investigating by attaching a debugger and setting a breakpoint on 'errfinish', then running the above query; past the backtrace here, as it might be illuminating. -- Įlvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services