Re: Entities created in one query not available in another in extended protocol

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Entities created in one query not available in another in extended protocol
Дата
Msg-id CANP8+jL2Loyf6tj4VkfTihAe+hjJSTKpt4JWGu_+zE3c4RmAvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Entities created in one query not available in another in extended protocol  (Shay Rojansky <roji@roji.org>)
Ответы Re: Entities created in one query not available in another in extended protocol
Список pgsql-hackers
On 11 June 2015 at 22:12, Shay Rojansky <roji@roji.org> wrote:
Thanks everyone for your time (or rather sorry for having wasted it).

Just in case it's interesting to you... The reason we implemented things this way is in order to avoid a deadlock situation - if we send two queries as P1/D1/B1/E1/P2/D2/B2/E2, and the first query has a large resultset, PostgreSQL may block writing the resultset, since Npgsql isn't reading it at that point. Npgsql on its part may get stuck writing the second query (if it's big enough) since PostgreSQL isn't reading on its end (thanks to Emil Lenngren for pointing this out originally).

That part does sound like a problem that we have no good answer to. Sounds worth starting a new thread on that.
 
Of course this isn't an excuse for anything, we're looking into ways of solving this problem differently in our driver implementation.

Shay

On Thu, Jun 11, 2015 at 6:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 11 June 2015 at 16:56, Shay Rojansky <roji@roji.org> wrote:

Npgsql (currently) sends Parse for the second command before sending Execute for the first one.

Look no further than that.



--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: On columnar storage
Следующее
От: Tom Lane
Дата:
Сообщение: Re: On columnar storage