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

Tom Lane wrote 2021-05-27 00:19:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> (I didn't add a Close Portal message to PQsendQueryInternal in 
>> pipeline
>> mode precisely because there is no such message in PQsendQueryGuts.
>> I think it would be wrong to unconditionally add a Close Portal 
>> message
>> to any of those places.)
> 
> Yeah, I'm not very comfortable with having libpq take it on itself
> to do that, either.

But...

Tom Lane wrote 2021-05-21 21:23:
> 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.

And given PQsendQueryParams should not be different from
PQsendQuery (aside of parameters sending) why shouldn't it close
its portal immediately, like it happens in exec_simple_query ?

I really doubt user of PQsendQueryPrepared is aware of portal as
well since it is also unnamed and also exhausted (because
PQsendQueryGuts always sends "send me all rows" limit).

And why PQsendQueryInternal should behave differently in pipelined
and not pipelined mode? It closes portal in not pipelined mode,
and will not close portal of last query in pipelined mode (inside
of transaction).

> Looking back at the original complaint, it seems like it'd be fair to
> wonder why we're still holding a page pin in a supposedly completed
> executor run.  Maybe the right fix is somewhere in the executor
> scan logic.

Perhaps because query is simple and portal is created as seek-able?

> 
> 			regards, tom lane

regards
Yura Sokolov