Re: Named Prepared statement problems and possible solutions

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: Named Prepared statement problems and possible solutions
Дата
Msg-id 5b068fff-be82-46f9-7757-3956950e6f07@garret.ru
обсуждение исходный текст
Ответ на Re: Named Prepared statement problems and possible solutions  (Dave Cramer <davecramer@gmail.com>)
Ответы Re: Named Prepared statement problems and possible solutions
Список pgsql-hackers


On 08.06.2023 6:18 PM, Dave Cramer wrote:


On Thu, 8 Jun 2023 at 11:15, Jan Wieck <jan@wi3ck.info> wrote:
On 6/8/23 10:56, Dave Cramer wrote:
>
>
>
>
> On Thu, 8 Jun 2023 at 10:31, Jan Wieck <jan@wi3ck.info
> <mailto:jan@wi3ck.info>> wrote:
>
>     On 6/8/23 09:53, Jan Wieck wrote:
>      > On 6/8/23 09:21, Dave Cramer wrote:
>      > The server doesn't know about all the clients of the pooler, does
>     it? It
>      > has no way of telling if/when a client disconnects from the pooler.
>
>     Another problem that complicates doing it in the server is that the
>     information require to (re-)prepare a statement in a backend that
>     currently doesn't have it needs to be kept in shared memory. This
>     includes the query string itself. Doing that without shared memory in a
>     pooler that is multi-threaded or based on async-IO is much simpler and
>     allows for easy ballooning.
>
>
> I don't expect the server to re-prepare the statement. If the server
> responds with "statement doesn't exist" the client would send a prepare.

Are you proposing a new libpq protocol version?

I believe we would need to add this to the protocol, yes.


So it will be responsibility of client to remember text of prepared query to be able to resend it when statement doesn't exists at server?
IMHO very strange decision. Why not to handle it in connection pooler (doesn't matter - external or embedded)?

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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Named Prepared statement problems and possible solutions
Следующее
От: Josef Šimánek
Дата:
Сообщение: Re: GTIN14 support for contrib/isn