On Thu, 8 Jun 2023 at 11:22, Konstantin Knizhnik <knizh...@garret.ru> wrote:
> > > On 08.06.2023 6:18 PM, Dave Cramer wrote: > > > > On Thu, 8 Jun 2023 at 11:15, Jan Wieck <j...@wi3ck.info> wrote: > >> On 6/8/23 10:56, Dave Cramer wrote: >> > >> > >> > >> > >> > On Thu, 8 Jun 2023 at 10:31, Jan Wieck <j...@wi3ck.info >> > <mailto:j...@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)? > I may be myopic but in the JDBC world and I assume others we have a `PreparedStatement` object which has the text of the query. The text is readily available to us. Also again from the JDBC point of view we have use un-named statements normally and then name them after 5 uses so we already have embedded logic on how to deal with PreparedStatements Dave
