>> This makes me wonder then if all it takes is just adding this to PortalDrop >> (proposed earlier in the thread by Frédéric):
> One thing I did not like about that approach is that we will need to > save the current debug_query_string inside PortalDrop before > temporarily setting it to the one from the about to be dropped > portal, and then set it back to the saved one before exiting. > Otherwise, we might end up logging the wrong query in some cases > (although I could not find a test case that proves my worry). After thinking about this a bit more, I found the test that breaks with v12. It is a bind statement in an implicit transaction. The portal will get dropped by the end of the transaction and will not reach drop_unnamed_portal. So, v13 takes Frederic's original idea, saves the pointer of debug_query_string, and resets it at the end of DropPortal. I also enhanced the test coverage. Debugging also shows that the STATEMENT: log is formed while we are in ExecutorEnd. We know that other extensions rely on QueryDesc->sourceText in that hook (i.e., pg_stat_statements), so this is another reason this approach appears safe, in addition to what was mentioned here [0] about the MessageContext outliving the portal. [0] https://www.postgresql.org/message-id/CAA5RZ0vB-h2pFimPSi72ObWfpRwKR5kaN9XWW17TOkLntC9svA%40mail.gmail.com -- Sami
v13-0002-Add-tests-for-temp-file-logging.patch
Description: Binary data
v13-0001-Fix-temp-file-logging-blame-in-extended-query.patch
Description: Binary data
