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 1m2udR-0006r8-FL for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 12:02:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m2udP-0003H4-EC for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 12:02:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2udP-0003Gv-60 for pgsql-performance@lists.postgresql.org; Mon, 12 Jul 2021 12:02:03 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m2udI-0007JZ-OB for pgsql-performance@postgresql.org; Mon, 12 Jul 2021 12:02:02 +0000 Received: by mail-wr1-x436.google.com with SMTP id f9so19583184wrq.11 for ; Mon, 12 Jul 2021 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=DLNCLHE3J3tWr9lf5bXxvXc9ewb8HtxGjM3TXKBpjpQ=; b=ZG+VyfNznrrA5C/Vr9tq/3f5pzdrX8A32jORB2q7w4qWDEP6fgAtcGUhArpLtK6tk5 2spsxYYdToRH6giQcBRX7JS/WqPRKkCxfTNvC/uUvDFudugQULGW1on8PNm3sKRB+Kvo AbGmPkLMRyfpJEfPgV9Oh6ARl+lm5Byigb11lXC8BTD58wpKGMiBQhk8a/qLh62/YcOw OnE1qFmriTfpNFRQ0pBGULQXMeE8VeC216ctOVx2hTo5qi6JvB233v38xtSnyNcQAmWp QMqOVt2gfCZ6NBxmugKWF8DUfqtGAWdkZ40RUlena4eBljKaCcIFjQ7goQzVFueWCAzt bwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=DLNCLHE3J3tWr9lf5bXxvXc9ewb8HtxGjM3TXKBpjpQ=; b=cWiCZxk5Tsmbyewxl2P+m1oiZv8avXRkjQ45sqMq0dTPGYwu9O7V9aqXIlOtovvJOy 2m0Y9zI9S+S5s39v+Joq/UJkCNjn1xyFxKAbEL6K7s3NJfVNed1Hcv1zxSm0dSnl1CJW 3ArfZIr/1/Ha+pGQxTLxEmIs3mhxqc4ysOb1CBE7RORtLMe0FLG9jn8/3L3qbr7gXYxn E98UTJlBquL/pVKXCH6bm08Qge1RsJI7hP0Yd4UGAkhbJmvmsx3Xx9agnSxp6DL1+ceQ PgrNJvDznpJXE087ZxYdTdQVDga06Pi/bbLzeKHgYpI7+7XBl1b++DsBTnO/SXmjz4+4 x2IQ== X-Gm-Message-State: AOAM531HiRBtANgC4HP7OnfPrFcZ5S7LNy/ADUldDM9d2IDx9jgFqHvQ QXx5kwV/fAmVpeCpV0pGgqjNOw== X-Google-Smtp-Source: ABdhPJxIfP37dVWi+UTLSZK69gsO4JKVfIhQglKAHcUlDAF7A91LP/qfVbvVkhp92J4CIBqNIrIN8A== X-Received: by 2002:adf:e107:: with SMTP id t7mr58580900wrz.165.1626091313801; Mon, 12 Jul 2021 05:01:53 -0700 (PDT) Received: from localhost.localdomain (217-149-171-247.nat.highway.telekom.at. [217.149.171.247]) by smtp.gmail.com with ESMTPSA id t3sm9191168wmi.14.2021.07.12.05.01.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 05:01:53 -0700 (PDT) Message-ID: <4827fef49e0d0410eedca61e235a16efc1d835de.camel@cybertec.at> Subject: Re: temporary file log lines From: Laurenz Albe To: MichaelDBA , PostgreSQL Performance Date: Mon, 12 Jul 2021 14:01:52 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2021-07-08 at 17:22 -0400, MichaelDBA wrote: > I got a question about PG log lines with temporary file info like this: > > case 1: log line with no contextual info > 2021-07-07 20:28:15 UTC:10.100.11.95(50274):myapp@mydb:[35200]:LOG: > temporary file: path "base/pgsql_tmp/pgsql_tmp35200.0", size 389390336 > > case 2: log line with contextual info > 2021-07-07 20:56:18 UTC:172.16.193.118(56080):myapp@mydb:[22418]:LOG: > temporary file: path "base/pgsql_tmp/pgsql_tmp22418.0", size 1048576000 > 2021-07-07 20:56:18 > UTC:172.16.193.118(56080):myapp@mydb:[22418]:CONTEXT: PL/pgSQL function > memory.f_memory_usage(boolean) line 13 at RETURN QUERY > > There are at least 2 cases where stuff can spill over to disk: > * queries that don't fit in work_mem, and > * temporary tables that don't fit in temp_buffers > > Question, if log_temp_files is turned on (=0), then how can you tell > from where the temporary log line comes from? > I see a pattern where work_mem spill overs have a CONTEXT line that > immediately follows the LOG LINE with keyword, temporary. See case 2 above. > > For other LOG lines with keyword, temporary, there is no such pattern. > Could those be the ones caused by temp_buffer spill overs to disk? case > 1 above. > > I really want to tune temp_buffers, but I would like to be able to > detect when temporary tables are spilling over to disk, so that I can > increase temp_buffers. > > Any help would be appreciated. I am not sure if you can istinguish those two cases from the log. What I would do is identify the problematic query and run it with EXPLAIN (ANALYZE, BUFFERS). Then you should see which part of the query creates the temporary files. If it is a statement in a function called from your top level query, auto_explain with the correct parameters can get you that output for those statements too. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com