log_temp_files associated with "wrong" statement

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: log_temp_files associated with "wrong" statement
Date: 2018-08-10 09:00:37
Message-ID: 0b33fac5-800b-6655-4da2-a0a373023ee0@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

log_temp_files makes a log entry when a temporary file is deleted.
Temporary file deletion is usually organized by the resource owner
mechanism. So usually it happens at the end of a query. But when the
query is run through a cursor, it happens whenever the cursor is closed.
So you might get a log entry like this:

LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp34451.4", size 115761152
STATEMENT: close foo;

That's a bit unhelpful, but at least you can gather some context.

It's even less helpful when the cursor is closed by the normal
transaction end, because then you can't tell from the log message which
cursor was involved:

LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp34451.4", size 115761152
STATEMENT: commit;

But where it gets really bad is if you use an unnamed portal, for
example through the JDBC driver. The unnamed portal is typically closed
when the next query is run. So the temporary file log entry is in the
logs associated with the next query. This can obviously lead to lots of
confusion when using this to debug query performance.

Thoughts on how to improve that? Perhaps we could optionally save a
reference to the portal, or the query string itself, in the Vfd
structure and use that to log?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Browse pgsql-hackers by date

  From Date Subject
Next Message KES 2018-08-10 09:10:47 Re: Typo in doc or wrong EXCLUDE implementation
Previous Message Peter Eisentraut 2018-08-10 08:39:57 Re: xact_start meaning when dealing with procedures?