Re: [BUG] temporary file usage report with extended protocol and unnamed portals
От | Frédéric Yhuel |
---|---|
Тема | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Дата | |
Msg-id | cad290a6-3d05-4060-823a-a6ac7504e1d9@dalibo.com обсуждение исходный текст |
Ответ на | Re: [BUG] temporary file usage report with extended protocol and unnamed portals (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Список | pgsql-hackers |
On 4/20/25 00:42, Sami Imseih wrote: >> (In my testing, the "temporary file:" message comes >> out without any attached STATEMENT most of the time already, so this >> isn't losing much as far as that's concerned.) Indeed, this happens when using autocommit / implicit transactions. But if you disable autocommit, and I think this is the most common setting, we do have the attached statement. > moreover, as I was looking into why the case mentioned earlier > > ``` > SELECT FROM foo ORDER BY a \bind > ; > SELECT 1 \bind > ; > ``` > > does not show STATEMENT after the temp file logging, I realized > it's because the temp files are cleaned up and reported at > the end of transaction, which means that debug_query_string is NULL at the > time the portal is dropped in the next query. This causes > check_log_of_query to return false. > > /* query string available? */ > if (debug_query_string == NULL) > return false; > Yes, we actually have two related bugs. >> Perhaps a cleaner answer is to rearrange things in postgres.c >> so that if there's a pre-existing unnamed portal, we drop that >> before we ever set debug_query_string and friends at all. > That did cross my mind as well, but I was trying to avoid doing this > type of rearranging. I still rather not go down that path considering the > case mentioned above will still not display the query text in a STATEMENT log. IMHO, it would be nice to fix the explicit transactions case. The bug with implicit transactions is less serious. I can try to implement Tom's idea if we have a consensus. Best regards, Frédéric
В списке pgsql-hackers по дате отправления: