Re: Add PortalDrop in exec_execute_message
От | Yura Sokolov |
---|---|
Тема | Re: Add PortalDrop in exec_execute_message |
Дата | |
Msg-id | df3a15ed0cb080fee80926220824c5b0@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Add PortalDrop in exec_execute_message (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: