I looked into this a bit more. What occurs during exec_bind_message is that the debug_query_string of the query is set early on. Later in that routine, a new portal is created via CreatePortal, which also drops the existing unnamed portal from the previous execution and which also logs the temp file information. So the logging is now using the debug_query_string of the current query and not the one referenced by the to-be-dropped portal.
This behavior means that there is a delay in log_temp_files logging, since the portal must be dropped, which can occur after the statement has completed execution. We can look into improving that, but I am not sure whether it is possible or can be done safely. I think the solution proposed by Frédéric seems reasonable: to switch the debug_query_string inside PortalDrop. However, I do not like the way the debug_query_string changes values after the CreatePortal call inside exec_bind_message; that seems incorrect. So, I believe we should temporarily switch the debug_query_string value only while running PortalDrop. Attached is what I think could be safer to do. What do you think? -- Sami Imseih Amazon Web Services (AWS)
v2-0001-Fix-race-condition-between-debug_query_string-and.patch
Description: Binary data
