From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
Date: Thu, 27 May 2021 14:45:50 +0300
Message-ID: <349ddd1e838c30b5efd3b14eb9345ccd@postgrespro.ru> (raw)
In-Reply-To: <202105262059.dnf27qpnccuv@alvherre.pgsql>
References: <202105262059.dnf27qpnccuv@alvherre.pgsql>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: y.sokolov@postgrespro.ru, alvherre@alvh.no-ip.org, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
In-Reply-To: <349ddd1e838c30b5efd3b14eb9345ccd@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox