Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 11 Nov 2025 08:31:26 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Drop unnamed portal immediately after execution to
 completion
Message-ID: <aRJ1zn0z-Bn0qc2H@paquier.xyz>
References: <E1vGWIt-0056al-2N@gemulon.postgresql.org>
 <CA+TgmoYFJyJNQw3RT7veO3M2BWRE9Aw4hprC5rOcawHZti-f8g@mail.gmail.com>
 <1982325.1762810082@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="TQDVnsVF08Ez+LXT"
Content-Disposition: inline
In-Reply-To: <1982325.1762810082@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/aRJ1zn0z-Bn0qc2H%40paquier.xyz>
Precedence: bulk


--TQDVnsVF08Ez+LXT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 10, 2025 at 04:28:02PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> This patch doesn't look well-considered to me. One problem is that
>> it's a wire protocol change to fix a minor logging anomaly, which
>> seems disproportionate. Another problem is that the new portal-drop
>> behavior is conditional on whether XACT_FLAGS_NEEDIMMEDIATECOMMIT gets
>> set, which seems unprincipled. In addition to those points, I am not
>> entirely certain that the "here is no need for it beyond this point"
>> comment is correct. I mean, I think it will normally be true, but what
>> if the client wants to send a Describe message after-the-fact, or an
>> additional Execute message that will presumably return zero rows?
>
> Yeah, the whole idea of changing the wire-level behavior to fix this
> has been making me itch: I don't believe for a moment that it won't
> cause compatibility problems.
>
> I do not have a better proposal for fixing the problem though.

All the other solutions mentioned mean to work around the issue of the
unnamed portal still being present by maintaining the query string it
in a different context across multiple messages.  And I doubt that
anybody would be thrilled by that.

If you think that we should continue to live with the protocol for
unnamed portals as-is and continue to live with the existing behavior,
meaning a revert of 1fd981f05369, that would not be the end of the
world here: we'd still have some tests that track the
past-and-currently-released behavior.

Even if strange, it works with the timing where the unnamed protocol
is dropped.  Perhaps somebody would be able to come up with a approach
better than a more aggressive portal drop once completed, but I don't
quite see how much can be done as long as we manipulate the unnamed
portals this way (aka drop then with a follow-up bind, and expect the
logging to show the correct statements attached to a previous
message that we have no knowledge about).  The original statement
logging did not really consider all these fancier cases with the
extended query protocol.
--
Michael

--TQDVnsVF08Ez+LXT
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmkSdc4ACgkQnvQgOdby
QH3MYQ/8DxYdqsM9W7Je+d6wlKl3PKArfKfY47AxbGXirCNdz5qm7r9wJmnRY5Xl
vsxA0PFgzzwjLaybPy9kOau9idW4J0Rw2mhyR6PuK0mpDrZ3JWNsrwjzZOFvUVBs
9fZCQaM9stFG5Mbh5owc3dG0ssg1qIkAbq7OpiLDpDYdWJPqBQvX7Y9sQxwde6f5
rbdfUYdyePe7k04aBvDxIAlTZKOh0prktq9OsVGkPqj7n9X83dj+g1RkxMS2GslL
rYJu4Lg13/E0YJpUFNLIKyLfsamVKswfdwhXc1n7qt5OpwP9JeOGwGiu6/r0ELiM
caOlxTVehV8WNAf0bPG3p6zgJS+Ku7OO+7SBw86w3L3kXizAzFJXj0rCEuXvMjsL
9N422QX7FZykUsY3fa7EWuLfcfCt2XeqPbHZdXdptgI1H/X3I6zWqT1ii+YQJFcA
UlqAx88IvjsZXIow/RL8DXgM+Rn7jCUw8Xe1HNCNa7wzNcwWkO4aXzq0BITcGGi7
u8A0qXf59EfuFUIqTuqhAZk2785Wj9/LC52vJ7KiKVDg16lJ9I40Ll0En6aCcn1h
q3m6RmpFJeTR6Sr/byO8NzrzO7qfCMscu3uzbypF86wgS6ftUGw8m1pI5TCagXen
QeQCUJN0DzLszs92dHjZpDEFPW0vXMfIh95LqxfFG/8lksFRGPI=
=S7Cu
-----END PGP SIGNATURE-----

--TQDVnsVF08Ez+LXT--