Skip to content
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

Closed
jesperpedersen opened this issue Mar 29, 2023 · 8 comments
Closed

max_connection_age #361

jesperpedersen opened this issue Mar 29, 2023 · 8 comments
Assignees
Labels
feature New feature

Comments

@jesperpedersen
Copy link
Collaborator

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.

@jesperpedersen jesperpedersen added the feature New feature label Mar 29, 2023
@fluca1978
Copy link
Collaborator

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:

  • in pgagroal_return_connection check if timestamp is greater than max_connection_age
  • if the above is true, goto kill_connection but probably there is something more to do in order to cleanup the connection

@jesperpedersen
Copy link
Collaborator Author

It is an option to remove a connection after a maximum amount of time.

So, it is pgagroal_return_connection - check - then goto kill_connection in that workflow

@2010YOUY01
Copy link
Contributor

I also want to make sure I get it right:
So the current implementation has a timestamp field inside struct connection, and an idle_timeout field inside struct configuration, they're used to make sure a connection won't stay in STATE_FREE (after returning back to the pool) longer
than idle_timeout.
This max_connection_age is to make sure the time from a connection successfully get from pgagroal_get_connection() (turned into STATE_INUSE) to pgagroal_return_connection() or idle check/validation won't longer than this specified time period.

@jesperpedersen
Copy link
Collaborator Author

@2010YOUY01 Yes

@2010YOUY01
Copy link
Contributor

Awesome, may I work on this issue?

@fluca1978
Copy link
Collaborator

@2010YOUY01 if you work on this, there is a function in the configuration code, named as_seconds that can parse the parameter.
Remember to keep the parameter consisten across configuration reloads, see ``metrics_cache_max_age` for an hint.

@hao-tian-xu
Copy link
Contributor

@2010YOUY01 Hi, I asked to find the issue to work on. Sorry for this..

hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 3, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 5, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 5, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 12, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 17, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 20, 2023
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`
hao-tian-xu added a commit to hao-tian-xu/pgagroal that referenced this issue Apr 20, 2023
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`
@jesperpedersen
Copy link
Collaborator Author

This has been merged - thanks @hao-tian-xu !

ashu3103 pushed a commit to ashu3103/pgagroal that referenced this issue Mar 2, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature
Projects
None yet
Development

No branches or pull requests

4 participants