[ Hit send too early, sorry. ] On Mon, Apr 15, 2024 at 1:43 PM Robert Haas <robertmh...@gmail.com> wrote: > But the wire protocol changes very slowly, and I think that is a > difference that actually matters quite a bit here. Broadly speaking, I > can use a psq
...a psql that I just built today to talk to a server from many years ago, and everything is fine. Sure, there are some marginal wire protocol changes around the edges, but not in places that are going to really affect the ability of psql to communicate. But I wouldn't try to run a psql built against 16 with a libpq even one major release old, and the other direction (older psql, newer libpq) also carries some (albeit fewer) risks. So the two situations aren't really entirely comparable, I feel. I don't quite know what to make of that as a practical matter: surely it can't be right to use protocol version 3.0 to refer to a bunch of different things. But at the same time, surely we don't want clients to start panicking and bailing out when everything would have been fine. > > To take it to the extreme: I think we should get to a state, where if > > we bump the protocol version at the client and server side without > > actually making any protocol changes, everything should continue to > > work fine. If we'd do that right now, then libpq wouldn't be able to > > connect to old postgres versions anymore. > > I think I agree with this, but it seems like a bootstrapping problem > and nothing more. That is, once we figure out how we want backward compatibility to work in general, I think we'll probably get pretty close to the state you want here pretty quickly. > > Clients might want to allow the user of the client to change regular > > parameters using ParameterSet (e.g. so that a connection pooler can > > intercept those ParameterSet messages and change its own behaviour if > > the parameter name is pgbouncer.pool_mode). But they wouldn't want a > > user to set any parameters that change the wire-protocol this way. And > > because an old client might connect to a new server a simple > > hard-coded list of parameters at the client side is not sufficient. > > > > I can see two ways around this: > > 1. Using a well-known prefix or namespace for parameters that change > > the wire protocol. (exact prefix to be bikeshedded on) > > 2. Using a hard-coded list at the client AND disallow changing > > PGC_PROTOCOL parameters at the server if the negotiated protocol > > version is lower than the version this parameter was introduced in AND > > bump the protocol version whenever we add a new PGC_PROTOCOL > > parameter. > > > > I think 1 is easier to implement at the client side, as it only > > requires a prefix comparison instead of keeping track of a list. I'm unconvinced that we should let ParameterSet change non-PGC_PROTOCOL GUCs. The pooler can agree on a list of protocol GUCs with the end client that differs from what the server agreed with the pooler - e.g., it can add pgbouncer.pool_mode to the list. But for truly non-protocol GUCs, we have a lot of ways to set those already. -- Robert Haas EDB: http://www.enterprisedb.com
