MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 27 May 2021 14:45:50 +0300
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
In-Reply-To: <202105262059.dnf27qpnccuv@alvherre.pgsql>
References: <202105262059.dnf27qpnccuv@alvherre.pgsql>
User-Agent: Roundcube Webmail/1.4.0
Message-ID: <349ddd1e838c30b5efd3b14eb9345ccd@postgrespro.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/349ddd1e838c30b5efd3b14eb9345ccd%40postgrespro.ru>
Precedence: bulk

Alvaro Herrera писал 2021-05-26 23:59:
> On 2021-May-25, Yura Sokolov wrote:
> 
>> Tom Lane писал 2021-05-21 21:23:
>> > Yura Sokolov <y.sokolov@postgrespro.ru> writes:
>> > > I propose to add PortalDrop at the 'if (completed)' branch of
>> > > exec_execute_message.
>> >
>> > This violates our wire protocol specification, which
>> > specifically says
>> >
>> >     If successfully created, a named portal object lasts till the end of
>> >     the current transaction, unless explicitly destroyed. 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. (Note that a simple Query message also destroys the unnamed
>> >     portal.)
>> >
>> > I'm inclined to think that your complaint would be better handled
>> > by having the client send a portal-close command, if it's not
>> > going to do something else immediately.
>> 
>> I thought about it as well. Then, if I understand correctly,
>> PQsendQueryGuts and PQsendQueryInternal in pipeline mode should send
>> "close portal" (CP) message after "execute" message, right?
> 
> I don't think they should do that.  The portal remains open, and the
> libpq interface does that.  The portal gets closed at end of 
> transaction
> without the need for any client message.  I think if the client wanted
> to close the portal ahead of time, it would need a new libpq entry 
> point
> to send the message to do that.

- PQsendQuery issues Query message, and exec_simple_query closes its
   portal.
- people doesn't expect PQsendQueryParams to be different from
   PQsendQuery aside of parameter sending. The fact that the portal
   remains open is a significant, unexpected and undesired difference.
- PQsendQueryGuts is used in PQsendQueryParams and PQsendQueryPrepared.
   It is always sends empty portal name and always "send me all rows"
   limit (zero). Both usages are certainly to just perform query and
   certainly no one expects portal remains open.

> (I didn't add a Close Portal message to PQsendQueryInternal in pipeline
> mode precisely because there is no such message in PQsendQueryGuts.

But PQsendQueryInternal should replicate behavior of PQsendQuery and
not PQsendQueryParams. Despite it has to use new protocol, it should
be indistinguishable to user, therefore portal should be closed.

> I think it would be wrong to unconditionally add a Close Portal message
> to any of those places.)

Why? If you foresee problems, please share your mind.

regards,
Sokolov Yura aka funny_falcon