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 1m2uoS-0007EV-0o for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 12:13:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m2uoQ-0001b3-L7 for pgsql-performance@arkaria.postgresql.org; Mon, 12 Jul 2021 12:13:26 +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 1m2uoQ-0001as-Ch for pgsql-performance@lists.postgresql.org; Mon, 12 Jul 2021 12:13:26 +0000 Received: from mout.perfora.net ([74.208.4.196]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2uoN-0007Oa-N4 for pgsql-performance@postgresql.org; Mon, 12 Jul 2021 12:13:25 +0000 Received: from [192.168.1.167] ([72.205.28.227]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LkeyA-1lSl6x03hE-00aWI7; Mon, 12 Jul 2021 14:13:19 +0200 Subject: Re: temporary file log lines To: Laurenz Albe Cc: PostgreSQL Performance References: <4827fef49e0d0410eedca61e235a16efc1d835de.camel@cybertec.at> From: MichaelDBA Message-ID: Date: Mon, 12 Jul 2021 08:13:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.48 MIME-Version: 1.0 In-Reply-To: <4827fef49e0d0410eedca61e235a16efc1d835de.camel@cybertec.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Provags-ID: V03:K1:7iAwDDs0BicPjXUdRG3VOIA8e69RF8bgC77kB3YwTfcfeDrLRzQ VxledoqDtO2tXo3nUXjf09n3D7WEwcxTGvvhTdiFymEy0HtHvfcWPWpy0yVK9GK3F3TQKyp T9FF21RvMNcLYQgl1nutW0Piddjc1N90EI2qgsR/SOGwtlCgqipUL7NX9S3QiPUUZeHBDsW cJMsIrgXaKoXm2J5kjevg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cRkw1pRD/nA=:LMKX8GyyA9kjEJKBHVey+a /jY79KkPgObgl2ll8mY93VI9zy5UmNn2zcYWWXYbk0fD+06Gi+h23rrbm8bO17wXTq2/t8iCI 554bEbSoP7qxfXUTOu2BXYmZg7lPRE/K0tLv//croJmqwyYczRpXIAGAMtnaGg6ZRBzRrXoJJ w7AEwmI3u4sDRCM8m4xW+stYTeWx5V7ddaeJdems/JY6olmJfehjA4/mqpA91uUwI9XBy8Ze7 sAUs+RcFbOLF1RA+8G7lgLEQy1SmlqdG1+5UHIduuav3AtZ/L2BW1jCgYaJM74tqk6+ziMOnn /C0ymfLdW7KgBciNiGsR3b6rV1nxl20Xq69m6sVvMQmejLbN1xzPiKev4KeRm2uy7E5gLUDUp se8cvWvJuxGb2NK+3+M6Vr3xpRTsn7zbXG60IsaCNUwvmUukkLI376S1LzBuroCAFKDqVCEuT dJ5Q9L2B0wL02Fll4QC4t87yGAIUyOcLFBYnq91xfeLcXGxj0aetwTHyeWyh/4nWAuCqqLLhf thfGxlusILN5kvyf4qOAGih5iPy2rcR0XIYyQUQPepchu7L8y/lM3DYh4gMQ7QneFSrt5ObPm WVcgreg2jlm2PXfA8ee4sacymGlhqALToLxleOz6/XJo8mjMup4U0KBVjl7HKQ8tALmSBnBSZ L0DbdxLx+tsmfDOkDsjik7v9NJCC++THH7VhgiJxfAs5CynuR5J8GorZMjAjdnFfWTb+pFcKe ZsJM0mgeqBSLY0wmATT7/E5KGSKGA3r5vhcMxkJ2PxQdZ5u6dH0mwI7QR6RWdGFCRc7+96MFe Jnre15GzAH/9OcNiBkRN7q2GwLhk8qJLQVjgIs9u20UKgaYb5h3/rvQHKkCb1nr7IUcrTPnFB nhmZVGoxU0TDzpjl7zuxTXOBjDCEU5i4flo9OXNbA= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk hmmm, I think spilling over to disk for temporary tables is handled by an entirely different branch in the PG source code.  In fact, some other folks have chimed in and said log_temp_files doesn't relate to temp files at all use by temporary tables, just queries as you mentioned below elsewhere.  This seems to be a dark area of PG that is not convered well. Regards, Michael Vitale Laurenz Albe wrote on 7/12/2021 8:01 AM: > 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