On Wed, Jun 5, 2024 at 1:50 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > Totally agreed, and that's easily achievable because of the > NegotiateProtocolVersion message. We're all good on v18 to v17 > connections and protocol changes, as long as we make any new behaviour > depend on either a protocol parameter or a protocol version bump.
Cool. > I think at minimum we'll need a mechanism for people to connect using > a StartupMessage that doesn't break existing poolers. If users have no > way to connect at all to their semi-recently installed connection > pooler with the newest libpq, then I expect we'll have many unhappy > users. I think it's debatable whether the compatible StartupMessage > should be opt-in or opt-out. I'd personally at minimum want to wait > one PG release before using the incompatible StartupMessage by > default, just to give pooler installs some time to catch up. I agree that we need such a mechanism, but if the driving feature is cancel-key length, I expect that opt-in isn't going to work very well. Opt-in seems like it would work well with compression or transparent column encryption, but few users will specify a connection string option just to get a longer cancel key length, so the feature won't get much use if we do it that way. I won't be crushed if we decide to somehow make it opt-in, but I kind of doubt that will happen. Would we make everyone add longcancelkey=true to all their connection strings for one release and then carry that connection parameter until the heat death of the universe even though after the 1-release transition period there would be no reason to ever use it? Would we rip the parameter back out after the transition period and break existing connection strings? Would we have people write protocolversion=3.1 to opt in and then they could just keep that in the connection string without harm, or at least without harm until 3.2 comes out? I don't really like any of these options that well. -- Robert Haas EDB: http://www.enterprisedb.com
