Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
От | Alvaro Herrera |
---|---|
Тема | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |
Дата | |
Msg-id | 20220615182633.ztcoloh7xbicggot@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
|
Список | pgsql-hackers |
On 2022-Jun-10, Kyotaro Horiguchi wrote: > (Moved to -hackers) > > At Wed, 8 Jun 2022 17:08:47 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in > > What that Close message is doing is closing the unnamed portal, which > > is otherwise closed implicitly when the next one is opened. That's how > > single-query mode works: if you run a single portal, it'll be kept open. > > > > I believe that the right fix is to not send that Close message in > > PQsendQuery. > > Agreed. At least Close message in that context is useless and > PQsendQueryGuts doesn't send it. And removes the Close message surely > fixes the issue. So, git archaeology led me to this thread https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql which is why we added that message in the first place. I was about to push the attached patch (a merged version of Kyotaro's and mine), but now I'm wondering if that's the right approach. Alternatives: - Have the client not complain if it gets CloseComplete in idle state. (After all, it's a pretty useless message, since we already do nothing with it if we get it in BUSY state.) - Have the server not send CloseComplete at all in the cases where the client is not expecting it. Not sure how this would be implemented. - Other ideas? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "That sort of implies that there are Emacs keystrokes which aren't obscure. I've been using it daily for 2 years now and have yet to discover any key sequence which makes any sense." (Paul Thomas)
Вложения
В списке pgsql-hackers по дате отправления: