From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Subject: | Re: NOT EXIST for PREPARE |
Date: | 2016-03-23 18:15:32 |
Message-ID: | CAB=Je-Es0uZtogqNBQHqsQ0OB_8A_1Lymvc7UgeUPxzzX-sYNQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin>No one is arguing that that you should send it any every time (at
least -- I hope not).
Well, what is your suggestion exactly?
pgjdbc is NOT using "prepare ..." sql command.
I'm inclined to suppose, it will not use "prepare..." even after your fix.
Merlin>Again, not in pooling scenarios
Merlin>The problems integrating server side
Merlin>prepared statements with pgbouncer are well known.
I'm afraid, they are not.
Your words are "This feature should be immediately be incorporated
by the JDBC driver" yet you have not raised that subject on pgsql-jdbc
mailing list/github issue. That is not very fair.
Let me just name an alternative, so you can see what "a step back" could be:
What if pg-bouncer generated _fake_ ParameterStatus(backend_id=...)
messages to pgjdbc?
Then pgjdbc can learn true backend session id and it can use proper
set of prepared statements. Basically, pgjdbc could have prepared statement
cache per backend_id.
Well, it is not a 100% solution, however it is yet another approach to
"pgbouncer" problem, and it will support all the PostgreSQL versions.
It fits into current frontend-backend protocol as all clients are supposed
to handle ParameterStatus messages, etc.
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-03-23 18:23:40 | Re: multivariate statistics v14 |
Previous Message | Peter Geoghegan | 2016-03-23 18:14:35 | Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |