You are browsing documentation for an outdated version.
See the latest documentation here.
Kong Gateway 3.3.x breaking changes
Before upgrading, review any configuration or breaking changes in this version and prior versions that
affect your current installation.
You may need to adopt different upgrade paths depending on your deployment methods, set of features in use,
custom plugins, for example.
For breaking changes to plugins, see the Kong Gateway Changelog for your Kong Gateway version.
The plugin queuing system was reworked in Kong Gateway 3.3.x, so some plugin parameters may not function as expected anymore. If you use queues in the following plugins, new parameters must be configured:
For more information about how plugin queuing works and the plugin queuing parameters you can configure, see About Plugin Queuing and Plugin Queuing Reference.
Traditional compatibility router
traditional_compat router mode has been made more compatible with the behavior of
traditional mode by splitting routes with multiple paths into multiple
atc routes with separate priorities. Since the introduction of the new router in Kong Gateway 3.0,
traditional_compat mode assigned only one priority to each route, even if different prefix path lengths and regular expressions were mixed in a route. This was not how multiple paths were handled in the
traditional router and the behavior has now been changed so that a separate priority value is assigned to each path in a route.
Upgrading Kong Gateway after adopting PostgreSQL 15
PostgreSQL 15 enforces different permissions on the public schema than prior versions of PostgreSQL. This requires an extra step to grant the correct permissions to the Kong user to make schema changes.
You can grant the permissions in one of two ways:
- Assign the Kong database owner to Kong by running
ALTER DATABASE kong OWNER TO kong.
- Temporarily give the Kong user the ability to modify the public schema and then revoke that permission. This option is more restrictive and is a two-part process:
- Before you run the bootstrap migration commands, grant the right to modify the schema with
GRANT CREATE ON SCHEMA public TO kong.
- After the migrations are done, remove this permission by running
REVOKE CREATE ON SCHEMA public FROM kong.