search

neondatabase / neon

Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, code-like database branching, and scale to zero.
https://neon.tech
Apache License 2.0
13.23k stars 370 forks source link

Support PostgreSQL protocol and protocol extension negotiation #7810

Open hlinnaka opened 1 month ago

hlinnaka commented 1 month ago

The PostgreSQL frontend-backend protocol supports protocol negotiation, so that if the client supports a higher version of the protocol than the server, they can agree to use the lowest common denominator. In practice, that never happens because there haven't been any new protocol versions since that mechanism was introduced. The protocol version is always 3.0. The same mechanism can also be used to negotiate the use of optional protocol extensions. That is also not used in practice because no optional protocol extensions have been introduced.

There were some patches in the v17 release cycle to introduce protocol changes that would've used that mechanism, but they were not committed. For future-proofing, it would be nice to support the protocol negotiation in the proxy.

See NegotiateProtocolVersion at https://www.postgresql.org/docs/devel/protocol-flow.html.

conradludgate commented 1 month ago

Problem:

  1. client <-> proxy - negotiates protocol version 3.1
  2. proxy <-> compute - negotiates protocol version 3.0
  3. client -> proxy -> compute - sends packet only on version 3.1

Needs to figure out how to resolve this early.

  1. Perhaps we just limit proxy to min version supported by all neon compute versions
  2. Alternatively deploy multiple proxies for different postgres (protocol) versions.
conradludgate commented 1 month ago

Alternative work around:

  1. Control plane should know the compute version per endpoint
  2. Proxy can cache this information
  3. Protocol version is dispatched after TLS handshake, meaning we should have the endpoint ID in SNI.
  4. If the endpoint name is unknown, and the protocol version is not 3.0, send back NegotiateProtocolVersion 3.0.
  5. If the endpoint name is known, but the compute version is uncached, and the protocol version is not 3.0, send back NegotiateProtocolVersion 3.0.
  6. If the endpoint name is known and the compute version is cached, negotiate based on the known supported protocol version of that compute version.
conradludgate commented 1 month ago

This would probably be less useful though. If a customer wants to make use of a new protocol feature, this would be inconsistent behaviour. I think I would prefer having different hostname/nlb/proxy per protocol version.