On 4/26/25 20:57, Sami Imseih wrote:
I found several issues with v4. It does not deal correctly with pipelining, and we should only really be concerned with dropping an unnamed portal only. So, v5 now moves the DropPortal call after the unnamed portal was executed to completion ( as v4 was doing ), but does so only in the case in which we are not inside a transaction-control statement or the portal was executing a command that can be run inside a transaction block.
I've tested your v5, and it works well. I've also attached a TAP test that checks the following cases:1. An unnamed statement followed by a simple query, both in the same transaction;
2. An unnamed statement in an implicit transaction; 3. Unnamed statements in pipeline mode.Patch handles these three cases correctly, while pre-patch blames the wrong query for cases 1. and 3., and logs no query at all for case 2.
Initially, I've tried to use pg_regress, but the query is only written in the server log (it is not sent to the frontend). Furthermore, the pid number in the first line of the log makes it impossible (it seems) to write the expected output file.
Also, I realize that explicit cursors ( DECLARE CURSOR ) will only log temp file at cursor close and in which case, the statement associated with the temp file logging is the CLOSE command: i.e. ``` 2025-04-26 18:46:38.084 UTC [10415] LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp10415.0", size 1014030336 2025-04-26 18:46:38.084 UTC [10415] STATEMENT: close mycursor_1; ``` I don't think there is much we can do there, or should we.
I don't think either. Best regards, Frédéric
008_log_temp_files.pl
Description: Perl program
