Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
Hi,
I know that this will probably get a staunch "No" as an answer, but...
I'm still going to ask: Would it be possible to backport 28b5726 to
the PG16 branch? Even though it's clearly a new feature?
I'm working on named prepared statement support in PgBouncer:
https://github.com/pgbouncer/pgbouncer/pull/845 That PR is pretty
close to mergable (IMO) and my intention is to release a PgBouncer
version with prepared statement support within a few months.
28b5726 allows sending Close messages from libpq, as opposed to
sending DEALLOCATE queries to deallocate prepared statements. Without
support for Close messages, libpq based clients won't be able to
deallocate prepared statements on PgBouncer, because PgBouncer does
not parse SQL queries and only looks at protocol level messages (i.e.
Close messages for deallocation).
Personally I think backpatching 28b5726 has a really low risk of
breaking anything. And since PgBouncer is used a lot in the Postgres
ecosystem, especially with libpq based clients, IMO it might be worth
deviating from the rule of not backporting features after a STABLE
branch has been cut. Otherwise all libpq based clients will have only
limited support for prepared statements with PgBouncer until PG17 is
released.
Jelte
On Wed, Aug 16, 2023 at 12:14:21AM +0200, Jelte Fennema wrote:
28b5726 allows sending Close messages from libpq, as opposed to
sending DEALLOCATE queries to deallocate prepared statements. Without
support for Close messages, libpq based clients won't be able to
deallocate prepared statements on PgBouncer, because PgBouncer does
not parse SQL queries and only looks at protocol level messages (i.e.
Close messages for deallocation).
The RMT has the final word on anything related to the release, but we
are discussing about adding something new to a branch that has gone
through two beta cycles with a GA targetted around the end of
September ~ beginning of October based on the trends of the recent
years. That's out of the picture, IMO. This comes once every year.
Personally I think backpatching 28b5726 has a really low risk of
breaking anything.
I agree about the low-risk argument, though. This is just new code.
--
Michael
On 2023-Aug-16, Michael Paquier wrote:
Personally I think backpatching 28b5726 has a really low risk of
breaking anything.I agree about the low-risk argument, though. This is just new code.
Here's a way to think about it. If 16.1 was already out, would we add
libpq support for Close to 16.2?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
On 8/15/23 15:39, Alvaro Herrera wrote:
On 2023-Aug-16, Michael Paquier wrote:
Personally I think backpatching 28b5726 has a really low risk of
breaking anything.I agree about the low-risk argument, though. This is just new code.
Here's a way to think about it. If 16.1 was already out, would we add
libpq support for Close to 16.2?
Seems pretty clearly a "no" to me.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com