-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
max_connection_age #361
Comments
What is the aim of killing a connection? I mean, isn't a way of augment latency, even if in favor of security? If I get it right, the workflow should be:
|
It is an option to remove a connection after a maximum amount of time. So, it is |
I also want to make sure I get it right: |
@2010YOUY01 Yes |
Awesome, may I work on this issue? |
@2010YOUY01 if you work on this, there is a function in the configuration code, named |
@2010YOUY01 Hi, I asked to find the issue to work on. Sorry for this.. |
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. Its implementation is very similar to `idle_timeout` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. Its implementation and functions are very similar to `idle_timeout` - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. Its implementation and functions are very similar to `idle_timeout` - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp`
This has been merged - thanks @hao-tian-xu ! |
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp` [agroal#378] Vault Implementaion [agroal#253][agroal#209] Refactor commands in `pgagroal-cli` and `pgagroal-admin` Now `pgagroal-cli` has a set of "logically" grouped commands and subcommands. For example, all the commands related to shutting down the pooler are under the `shutdown` command, that can operate with subcommands like `gracefully`, `immediate` or `cancel`. In order to provide this capability, new functions have been introduced as utilities: - `parse_command()` accepts the command line and seek for a command, possibly its subcommand, and an optional "value" (often the database or server name). - `parse_command_simple()` is a wrapper around the above `parse_command` that shorten the function call line because it does not require to specify the key and the value (and their defaults). - `parse_deprecated_command()` does pretty much the same thing but against the old command. Thanks to this, old commands can still work and the user will be warned about their deprecation, but the interface of `pgagroal-cli` is not broken. All the above functions require to know the offset at which start seeking for a command, and that depends on the number of options already parsed via `getopt_long()`. Since the `&option_index` is valued only for long options, I decided to use the `optind` global value, see getopt_long(3). This value is initialized with the "next thing" to seek on the command line, i.e., the next index on `argv`. In the case the command accepts an optional database name, the database value is automatically set to '*' (all databases) in case the database name is not found on the command line. Therefore: pgagroal-cli flush idle is equivalent to pgagroal-cli flush idle '*' On the other hand, commands that require a server name get the value automatically set to "\0" (an invalid server name) in order to "block" other pieces of code. Moroever, if the server has not been specified, the command is automatically set to "unknown" so that the help screen is shown. The `pgagroal-cli` has a set of `pgagroal_log_debug()` calls whenever a command is "parsed", so that it is possible to quickly follow the command line parsing. Also, since the `pgagroal-cli` exists if no command line arguments have been specified, the safety check aboutt `argc > 0` around the command line parsing has been removed. In the case the user specified an unknown command, she is warned on stdout before printing the `usage()` help screen. Deprecated commands are notified to the user via a warning message, printed on stderr, that provides some hints about the correct usage of the new command. The warning about deprecated commands is shown only if the currently running version of the software is greater than the version the command has been deprecated onto. In particular these commands have been deprecated since 1.6. This commit also introduces the command refactoring for `pgagroal-admin` in a way similar to the work done for `pgagroal-cli`. New commands are available: - user <what> with <what> being <add>, <del>, <edit>, <ls>. Updated: - documentation - shell completions - help screens - examples Close agroal#290 agroal#253 [agroal#381] Changes to `pgagroal-cli` commands This commit changes two commands in `pgagroal-cli`. The `is-alive` command is deprecated by means of the `ping` command. Documentation has been modified accordingly. The `details` command is now deprecated by the `status details` one. To achieve this, the `status details` is parsed _before_ the `status` one (that has not changed at all). In order to better reflect this change, the internal constant `ACTION_DETAILS` has been renamed to `ACTION_STATUS_DETAIL`. Documentation updated accordingly. Shell completions updated accordingly. Close agroal#381 [agroal#378] Vault Implementation
Create a
max_connection_age
setting that will define how long a connection will live - in seconds.This configuration option will be checked once the connection is returned to the pool, or during the idle check.
Default is
-1
- e.g. not enabled.The text was updated successfully, but these errors were encountered: