Re: [BUG] temporary file usage report with extended protocol and unnamed portals

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>, Guillaume Lelarge <guillaume(dot)lelarge(at)dalibo(dot)com>, Pierrick Chovelon <pierrick(dot)chovelon(at)dalibo(dot)com>
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Date: 2025-08-21 12:02:40
Message-ID: d62faa12-5a83-4612-9bd3-bc9691f04d2b@dalibo.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Having taken another look at this patch, I believe it is problematic as
it does not align with the protocol documentation, which states:

"An unnamed portal is destroyed at the end of the transaction, or as
soon as the next Bind statement specifying the unnamed portal as
destination is issued."

Attached is another patch that strictly adheres to Tom's earlier
proposal in this thread:

> 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.

This v6 patch includes the TAP test that I sent in my previous email,
with some enhancements.

From a user's point of view, Sami's patch is much better, because it
always logs the right query (except for the SQL cursor), whereas this
one doesn't log any queries in certain cases. However, it appears
challenging to devise a clean solution that accomplishes our desired
outcome.

Best regards,
Frédéric

Attachment Content-Type Size
v6-0001-Fix-reporting-of-temp-files-usage.patch text/x-patch 5.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2025-08-21 12:17:19 Re: Add GUC to enable libxml2's XML_PARSE_HUGE
Previous Message jian he 2025-08-21 11:59:14 misleading error message in ProcessUtilitySlow T_CreateStatsStmt