pgagroal is a high-performance protocol-native connection pool for PostgreSQL.

Overview

pgagroal

pgagroal is a high-performance protocol-native connection pool for PostgreSQL.

Pronounced: p-g-a-gro-al, named after Agroal in Portugal.

Features

  • High performance
  • Connection pool
  • Limit connections for users and databases
  • Prefill support
  • Remove idle connections
  • Perform connection validation
  • Enable / disable database access
  • Graceful / fast shutdown
  • Prometheus support
  • Grafana 8 dashboard
  • Remote management
  • Authentication query support
  • Failover support
  • Transport Layer Security (TLS) v1.2+ support
  • Daemon mode
  • User vault

See Getting Started on how to get started with pgagroal.

See Configuration on how to configure pgagroal.

See Performance for a performance run.

Overview

pgagroal makes use of

  • Process model
  • Shared memory model across processes
  • libev for fast network interactions
  • Atomic operations are used to keep track of state
  • The PostgreSQL native protocol v3 for its communication

pgagroal will work with any PostgreSQL compliant driver, for example pgjdbc, Npgsql and pq.

See Architecture for the architecture of pgagroal.

Tested platforms

Compiling the source

pgagroal requires

dnf install git gcc cmake make libev libev-devel openssl openssl-devel systemd systemd-devel python3-docutils

Alternative clang 8+ can be used.

Release build

The following commands will install pgagroal in the /usr/local hierarchy and run the default configuration.

git clone https://github.com/agroal/pgagroal.git
cd pgagroal
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make
sudo make install
/usr/local/bin/pgagroal -c /usr/local/etc/pgagroal/pgagroal.conf -a /usr/local/etc/pgagroal/pgagroal_hba.conf

See RPM for how to build a RPM of pgagroal.

Debug build

The following commands will create a DEBUG version of pgagroal.

git clone https://github.com/agroal/pgagroal.git
cd pgagroal
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
cd src
cp ../../doc/etc/*.conf .
./pgagroal -c pgagroal.conf -a pgagroal_hba.conf

Remember to set the log_level configuration option to debug5.

Contributing

Contributions to pgagroal are managed on GitHub.com

Contributions are most welcome !

Please, consult our Code of Conduct policies for interacting in our community.

Consider giving the project a star on GitHub if you find it useful. And, feel free to follow the project on Twitter as well.

License

BSD-3-Clause

Issues
  • Connection leaking in 0.9.0

    Connection leaking in 0.9.0

    Describe the bug

    Clients couldn't get new connections after upgrading to 0.9.0 , rolling back to 0.8.2 resolves the issue. All clients utilize connection pooling (either jdbc or libpq based) with pool size of 2~3, connection life-time set to 60s, the number of active connections is very stable.

    active_connections: Screenshot_2020-09-26T19:10:40+09:00

    total_connections: Screenshot_2020-09-26T19:15:35+09:00

    To Reproduce

    Steps to reproduce the behavior.

    Version

    What is the version of pgagroal ?

    PostgreSQL

    What is the version of PostgreSQL ?

    12.4-1.pgdg18.04+1

    libev

    What is the version of libev ?

    1:4.22-1

    OpenSSL

    What is the version of OpenSSL ?

    1.1.1-1ubuntu2.1~18.04.6

    Access method

    Which security access method is used (trust, password, md5, scram-sha-256) ?

    md5

    OS

    Which Operating System (OS) is used ?

    ubuntu 18.04

    ulimit

    What is the output from ulimit -a ? 5000

    Configuration

    Can you provide the configuration pgagroal ?

    • pgagroal.conf
    [pgagroal]
    host = 0.0.0.0
    port = 5555
    metrics = 5556
    management = 5557
    
    log_type = console
    log_level = info
    log_path = 
    
    max_connections = 120
    idle_timeout = 1
    validation = off
    unix_socket_dir = /tmp/.s.pgagroal
    
    pipeline = session
    
    [primary]
    host = prod-pg01-a
    port = 5432
    

    Debug logs

    Can you provide any debug logs (log_level = debug5) of the issue ?

    Tip

    I compiled pgagroal myself, packages are up-to-date

    apt install wget libev4 libev-dev libssl1.1 libssl-dev systemd libsystemd-dev python-docutils gcc-8 cmake -y
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
    
    bug 
    opened by yaroot 28
  • still autoreconnect not working on postgresql restart

    still autoreconnect not working on postgresql restart

    ##################################### pgagroal.conf ##################################### [pgagroal] host = localhost port = 9091

    log_type = console log_level = info log_path =

    max_connections = 1000 idle_timeout = 600 validation = foreground unix_socket_dir = /tmp/.s.pgagroal libev=select log_connections = true log_disconnections = true

    [primary] host = localhost port = 9081

    ##################################### pgagroal version ##################################### $ pgagroal -V (git clone... using latest source!) pgagroal 0.6.0

    $ cat pg_start.sh #!/bin/bash pgagroal -c pgagroal.conf -a pgagroal_hba.conf -l pgagroal_databases.conf -u pgagroal_users.conf

    STAGE$ ./pg_start.sh 04-02 08:24:12.842 17741 17741 I pgagroal.main pgagroal: started on localhost:9091 04-02 08:24:13.356 18052 18052 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:13.554 18067 18067 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:13.555 18068 18068 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:13.559 18069 18069 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:13.559 18069 18069 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:13.560 18070 18070 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:13.560 18070 18070 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:18.259 20207 20207 I pgagroal.worker connect: address=:: 04-02 08:24:18.260 20207 20207 I pgagroal.worker disconnect: address=:: 04-02 08:24:33.257 25631 25631 I pgagroal.worker connect: address=:: 04-02 08:24:33.257 25631 25631 I pgagroal.worker disconnect: address=:: 04-02 08:24:43.069 18068 18068 I pgagroal.worker disconnect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:43.075 18067 18067 I pgagroal.worker disconnect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:43.095 18052 18052 I pgagroal.worker disconnect: user=tarantula database=tarantula address=127.0.0.1 04-02 08:24:43.460 31505 31505 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:43.460 31505 31505 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:43.636 31511 31511 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:43.636 31511 31511 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:43.650 31512 31512 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:43.650 31512 31512 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:46.051 32263 32263 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:46.051 32263 32263 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:46.149 31799 31799 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:46.149 31799 31799 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:46.257 31904 31904 I pgagroal.worker connect: address=127.0.0.1 04-02 08:24:46.257 31904 31904 I pgagroal.worker disconnect: address=127.0.0.1 04-02 08:24:48.265 684 684 I pgagroal.worker connect: address=:: 04-02 08:24:48.265 684 684 I pgagroal.worker disconnect: address=::

    ################################## before postgresql restart ################################## STAGE$ nc -vz localhost 9091 localhost [127.0.0.1] 9091 (?) open [[email protected]:/home/postgres] STAGE$

    ################################## db restart ################################## postgresql restart -w -c

    ################################## after postgresql restart ################################## [[email protected]:/home/postgres] STAGE$ nc -vz localhost 9091 localhost [127.0.0.1] 9091 (?) : Connection refused <============ pgagroal die ??? [[email protected]:/home/postgres]

    STAGE$ nc -vz localhost 9091 localhost [127.0.0.1] 9091 (?) : Connection refused [[email protected]:/home/postgres] STAGE$

    after 5 minutes .......................

    [[email protected]:/home/postgres] STAGE$ nc -vz localhost 9091 localhost [127.0.0.1] 9091 (?) : Connection refused <===== still refused [[email protected]:/home/postgres] STAGE$

    bug 
    opened by hellower 23
  • Config error messages

    Config error messages

    As per discussion https://github.com/agroal/pgagroal/discussions/199, this implements a better warning message for limits that go beyond the availability of connections.

    The end result is:

    DEBUG configuration.c:1314 limit entry 0 with max_size = 50 exceeds remaining available connections 10. Line: pgbench pgbench 50 10  5
    
    WARN  configuration.c:1320 max_size greater than remaining available connections at entry 1 (line 2 of file /etc/pgagroal/pgagroal_databases.conf), adjusting max_size to zero for this entry
    
    FATAL configuration.c:1388 max_size must be greater than 0 for limit entry 1
    

    the DEBUG and WARN are added messages that explain when the user should look at to fix the problem. Only one warning message is printed out, even if the subsequent entries are zeroed too. This attaches also a lineno field to the limit struct to keep track of the configruation line, in order to help the user to fix the problem.

    enhancement 
    opened by fluca1978 17
  • [#224] Prefill when doing a `switch-to` or primary change.

    [#224] Prefill when doing a `switch-to` or primary change.

    Whenever the primary host is changed, by means of an explicit switch-to command or by a primary failure, the connection flushing is activated. If possible, the prefill should be also restored on the new server. As suggested in https://github.com/agroal/pgagroal/pull/225#issuecomment-1117218107 it would be nice to check if the specified new server is the same as the old one (failure of the primary) or a different one (switch-to), and in the case they are different the prefill is forced.

    enhancement 
    opened by fluca1978 16
  • Problem in pgagroal.service ?

    Problem in pgagroal.service ?

    Hello,

    Service does not start

    # systemctl start pgagroal
    Job for pgagroal.service failed because a timeout was exceeded.
    See "systemctl status pgagroal.service" and "journalctl -xe" for details.
    

    However logs shows:

    févr. 03 09:56:19 linux2 systemd[1]: Starting High-performance connection pool for PostgreSQL...
    févr. 03 09:56:19 linux2 pgagroal[10275]: pgagroal[10275]: pgagroal: started on  :0
    févr. 03 09:56:19 linux2 pgagroal[10275]: pgagroal: started on  :0
    ...
    févr. 03 09:57:49 linux2 pgagroal[10275]: pgagroal[10275]: pgagroal: shutdown
    févr. 03 09:57:49 linux2 pgagroal[10275]: pgagroal: shutdown
    févr. 03 09:57:49 linux2 systemd[1]: pgagroal.service: Failed with result 'timeout'.
    févr. 03 09:57:49 linux2 systemd[1]: Failed to start High-performance connection pool for PostgreSQL.
    

    A communication problem between systemd and pgagroal ?

    OS: ArchLinux pgagroal: 1.1.0

    bug 
    opened by mrechte 14
  • unable to set max_connections parameter

    unable to set max_connections parameter

    unable to set max_connections parameter getting error below while starting pgagroal with max_connections=2000. pgagroal: max_connections is larger than the number of available file descriptors for connections (994)

    question 
    opened by ghost 12
  • [#219] Provide Prometheus metrics cache

    [#219] Provide Prometheus metrics cache

    This commit refactors the way the Prometheus metrics are served in order to provide the capability to cache the responses for a specified amount of time.

    A new setting, named metrics_cache is defined and parsed as an "age" string. The value will be stored as a number of seconds. This required the refactoring of some configuration code, with particular regard to as_logging_rotation_age() in order to extract the "as age" logic into an utility function that can be used for different "age"-like strings. Moreover, some methods and configuration parameters have been changed from int to unsigned int (e.g., it does not make any sense to have a log rotation age negative!). The configuration related code has been changed to intercept wrong strings, e.g., when log_rotation_age = -2m the system disables the rotation and warns the user as the parameter is unknown. Also +1m is considered a bogus string.

    The struct prometheus has been expanded with an inner struct, named struct prometheus_cache that holds the cache payload and the timestamp the cache will be valid until.

    The metrics_page() has been refactored to check if the cache is configured and valid, in such case the response is served out of cache. On the other hand, the cache is reset and the response is served as a new one, with all the inner methods adding the result to the cache for the next time. A few utility functions have been introduced:

    • is_metrics_cache_configured() checks that the current configuration allows for the usage of cache, i.e., metrics_cache have been set;
    • is_metrics_cache_valid() checks hat the cache does handle some good stuff to be served;
    • metrics_cache_reset() to reset the cache, once it has been set within the shared memory;
    • metrics_cache_add() appends data to the cache. This methods is invoked whenever a new Prometheus message is spurt. In the case the overall amount of data overflows, the cache is made not valid. It is safe to call this function everywhere because it does nothing if the caching system is not enabled.

    If the cache overflows, it is set to "invalid" so that is not gong to be served anymore. The max size of the cache is defined as a constant value within the source code, and is set to 8kB (that should be reasonable since the average Prometheus response on a unloaded server is around 4kB).

    The documentation has been updated to reflect changes.

    Close #219

    feature 
    opened by fluca1978 11
  • Add new metric pgagroal_connection_query_count and new panel

    Add new metric pgagroal_connection_query_count and new panel "Query rate per database"

    The metric pgagroal_connection_query_count shows the number of queries per connection.

    The new panel "Query rate per database" shows query rate per db based on pgagroal_connection_query_count.

    opened by An-DJ 11
  • prefill after switch-to

    prefill after switch-to

    Don't know if this is a valuable feature, but with 1.5 when I do a switch-to and/or a reset-server the prefill seems to be dropped. I mean, when I start pgagroal the "initial" connections from pgagroal_databases.conf are established. When I do a switch-to to another server, the new server does not get the "initial" connection number but only the "minimum". The same when I come back with another switch-to the original server. Is there a reason or should pgagroal honor the "initial" connection every time a server is changed as primary?

    enhancement 
    opened by fluca1978 10
  • too many Bad file descriptor

    too many Bad file descriptor

    Describe the bug too many bad file descriptior

    To Reproduce just start..

    Version git clone -- latest version

    PostgreSQL 11.7

    Access method md5

    OS debian 10

    Additional information Can you provide the configuration of pgagroal ? Can you provide any debug logs of the issue ?

    --------------- detail  info ...........................
    
    __STAGE__# cat /etc/os-release 
    PRETTY_NAME="Debian GNU/Linux 10 (buster)"
    NAME="Debian GNU/Linux"
    VERSION_ID="10"
    VERSION="10 (buster)"
    VERSION_CODENAME=buster
    ID=debian
    HOME_URL="https://www.debian.org/"
    SUPPORT_URL="https://www.debian.org/support"
    BUG_REPORT_URL="https://bugs.debian.org/"
    [[email protected]:/tmp/pgagroal]
    __STAGE__# ls
    pgagroal.conf  pgagroal_databases.conf  pgagroal_hba.conf  pgagroal_users.conf  start.sh*
    [[email protected]:/tmp/pgagroal]
    __STAGE__# cat pgagroal.conf 
    [pgagroal]
    host = localhost
    port = 9091
    
    log_type = console
    log_level = info
    #log_path =  /tmp/pgagroal.log
    
    max_connections = 1000
    idle_timeout = 600
    validation =  off
    unix_socket_dir = /tmp/.s.pgagroal
    
    log_connections = true
    log_disconnections = true
    
    [primary]
    host = localhost
    port = 9081
    [[email protected]:/tmp/pgagroal]
    __STAGE__# cat pgagroal_databases.conf 
    #
    # DATABASE USER  MAX_CONNECTIONS INITIAL_SIZE
    #
    #all        all   all
    tarantula tarantula 200 10
    tarantula kong        5  3
    [[email protected]:/tmp/pgagroal]
    __STAGE__# cat pgagroal_hba.conf 
    #
    # TYPE  DATABASE USER  ADDRESS  METHOD
    #
    host    all      all   all      all
    [[email protected]:/tmp/pgagroal]
    __STAGE__# cat pgagroal_users.conf 
    tarantula:blabla.......................
    kong:blabla.......................
    [[email protected]:/tmp/pgagroal]
    __STAGE__# cat start.sh 
     pgagroal -c pgagroal.conf  -a pgagroal_hba.conf -l pgagroal_databases.conf -u pgagroal_users.conf
    [[email protected]:/tmp/pgagroal]
    
    ==========
    
    CONTAINER$ ./pg_start.sh 
    03-23 10:02:44.960   424   424 I pgagroal.main pgagroal: started on localhost:9091
    03-23 10:02:45.267   430   430 I pgagroal.worker connect: address=127.0.0.1 
    03-23 10:02:45.267   430   430 I pgagroal.worker disconnect: address=127.0.0.1
    03-23 10:02:45.276   431   431 I pgagroal.worker connect: address=127.0.0.1 
    03-23 10:02:45.276   431   431 I pgagroal.worker disconnect: address=127.0.0.1
    03-23 10:02:45.873   443   443 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 
    03-23 10:02:45.926   444   444 I pgagroal.worker connect: address=127.0.0.1 
    03-23 10:02:45.926   444   444 I pgagroal.worker disconnect: address=127.0.0.1
    03-23 10:02:46.273   448   448 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 
    03-23 10:02:46.942   454   454 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 
    03-23 10:02:48.515   464   464 I pgagroal.worker connect: address=:: 
    03-23 10:02:48.515   464   464 I pgagroal.worker disconnect: address=::
    03-23 10:02:53.126   475   475 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 
    03-23 10:02:53.126   475   475 I pgagroal.worker connect: user=tarantula database=tarantula address=127.0.0.1 
    03-23 10:03:03.452   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.453   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.454   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.454   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.454   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.455   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.455   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.456   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:03.457   424   424 W pgagroal.main accept: 4 Bad file descriptor
    ............
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    03-23 10:03:06.643   424   424 W pgagroal.main accept: 4 Bad file descriptor
    
    bug 
    opened by hellower 10
  • [#105] Blocked connections metrics

    [#105] Blocked connections metrics

    Creates a new metric named "connection awaiting" to keep track of the number of connection enqueued but not served due to a reached limit.

    This commit introduces a new field in the prometheus structure named connection_awaiting to keep track of the connections that have been suspended due to blocking_timeout configuration parameter. Whenever a connection is suspended by the pool, the pgagroal_prometheus_connection_awaiting() function is invoked to increment the counter of awaiting connections, and following the opposite happens with the pgagroal_prometheus_connection_unawaiting() that decrements the counter, since the connection workflow is going to restart (or abort).

    The metric is exported as pgagroal_connection_awaiting.

    Close #105

    feature 
    opened by fluca1978 9
  • [#287] Fix link in documentation

    [#287] Fix link in documentation

    The HBA section in the documentation refers to the PostgreSQL pg_hba.conf file format, and therefore should link to the right place within the documentation.

    Close #287

    opened by fluca1978 0
  • PostgreSQL HBA file link in documentation

    PostgreSQL HBA file link in documentation

    In the documentation, within the pgagroal_hba configuration section, there is a link to PostgreSQL website while it should be there a link to the HBA configuration format.

    opened by fluca1978 0
  • [#285] Introduce `update_process_title` setting

    [#285] Introduce `update_process_title` setting

    This commit adds the update_process_title configuration setting. Values for such setting are:

    • never or off, means the user does not want to update the process title at all;
    • strict (used on Linux and systems that do no provide a native call to update the process title) allows for changing the process title without overflowing the length of the initial command line;
    • minimal sets the process title to user/database even if this exceeds the initial command line length;
    • verbose sets the process title to [email protected]:port/database even if this overflows the initial command line length.

    By default the setting is configured as verbose, but this could break some aggressively secured environments, where no native way to set the process title is provided.

    The pgagroal_set_proc_title function has been refactored so that, if the update policy is set to never the process title will never be updated. This can be confusing because even the "main" process will not have a title update. Likely, if the policy is strict, the function will never try to overflow the initial command line length.

    On those systems that do provide a native way to set the process title, there is no difference between strict and minimal and the minmal policy is always adopted.

    Documentation updated.

    Close #285

    opened by fluca1978 0
  • Create an `update_process_title` setting

    Create an `update_process_title` setting

    See discussion related to #215 here https://github.com/agroal/pgagroal/pull/284#issuecomment-1171195925. Provide a configuration setting, likely update_process_title, that can have values within the range:

    off - Don't touch anything
    strict - <= strlen(argv)
    minimal - user/database
    verbose - [email protected]:port/database (default)
    

    and call pgagroal_set_proc_title and friends depending on such configuration setting.

    feature 
    opened by fluca1978 0
  • Refactor command names in `pgagroal-cli`

    Refactor command names in `pgagroal-cli`

    The pgagroal-cli command has, according to me, some inconsistency within the commands. For example:

    • gracefully does a graceful shutdown;
    • cancel-shutdown does cancel the above request (but no "gracefully" appears in the name)
    • stop does a not graceful halt of the system.

    I propose to choose a common word, e.g., shutdown and add a subcommand to specify the shutdown method:

    • shutdown will result to be the same as gracefully
    • shutdown immediately will result the same as stop
    • cancel-shutdown will remain the same and now it is clear which commands are related to the shutdown.

    Same thing for the flush-xxx commands that can become flush with a subcommand related to the mode, e.g., flush gracefully.

    The reset command is tied to the Prometheus info, and reset-server is the one that does reset a configured server. Appears to me it is better to have the reset command to be tied to the working of pgagroal, not of Prometheus, because it is more important and the metrics could be an optional feature (meaning it is not enabled).

    Old commands should remain, to avoid breaking working clients and batches, and should report on stderr that the command has been deprecated.

    feature 
    opened by fluca1978 6
Releases(1.4.2)
Owner
Agroal
High-performance connection pools for databases
Agroal
PolarDB for PostgreSQL (PolarDB for short) is an open source database system based on PostgreSQL.

PolarDB for PostgreSQL (PolarDB for short) is an open source database system based on PostgreSQL. It extends PostgreSQL to become a share-nothing distributed database, which supports global data consistency and ACID across database nodes, distributed SQL processing, and data redundancy and high availability through Paxos based replication. PolarDB is designed to add values and new features to PostgreSQL in dimensions of high performance, scalability, high availability, and elasticity. At the same time, PolarDB remains SQL compatibility to single-node PostgreSQL with best effort.

Alibaba 2.3k Jun 30, 2022
High-performance time-series aggregation for PostgreSQL

PipelineDB has joined Confluent, read the blog post here. PipelineDB will not have new releases beyond 1.0.0, although critical bugs will still be fix

PipelineDB 2.5k Jun 24, 2022
A framework to monitor and improve the performance of PostgreSQL using Machine Learning methods.

pg_plan_inspector pg_plan_inspector is being developed as a framework to monitor and improve the performance of PostgreSQL using Machine Learning meth

suzuki hironobu 168 Jul 1, 2022
OceanBase is an enterprise distributed relational database with high availability, high performance, horizontal scalability, and compatibility with SQL standards.

What is OceanBase database OceanBase Database is a native distributed relational database. It is developed entirely by Alibaba and Ant Group. OceanBas

OceanBase 4.4k Jun 27, 2022
React-native-quick-sqlite - ⚡️ The fastest SQLite implementation for react-native.

React Native Quick SQLite The **fastest** SQLite implementation for react-native. Copy typeORM patch-package from example dir npm i react-nati

Oscar Franco 280 Jun 22, 2022
The official C++ client API for PostgreSQL.

libpqxx Welcome to libpqxx, the C++ API to the PostgreSQL database management system. Home page: http://pqxx.org/development/libpqxx/ Find libpqxx on

Jeroen Vermeulen 643 Jun 25, 2022
A PostgreSQL extension providing an async networking interface accessible via SQL using a background worker and curl.

pg_net is a PostgreSQL extension exposing a SQL interface for async networking with a focus on scalability and UX.

Supabase 41 Jun 19, 2022
Prometheus exporter for PostgreSQL

pgexporter pgexporter is a Prometheus exporter for PostgreSQL. pgexporter will connect to one or more PostgreSQL instances and let you monitor their o

null 15 Apr 17, 2022
PostgreSQL extension for pgexporter

pgexporter_ext pgexporter_ext is an extension for PostgreSQL to provide additional Prometheus metrics for pgexporter. Features Disk space metrics See

null 4 Apr 13, 2022
The PostgreSQL client API in modern C++

C++ client API to PostgreSQL {#mainpage} Dmitigr Pgfe (PostGres FrontEnd, hereinafter referred to as Pgfe) - is a C++ client API to PostgreSQL servers

Dmitry Igrishin 134 Jun 3, 2022
A friendly and lightweight C++ database library for MySQL, PostgreSQL, SQLite and ODBC.

QTL QTL is a C ++ library for accessing SQL databases and currently supports MySQL, SQLite, PostgreSQL and ODBC. QTL is a lightweight library that con

null 155 Jun 26, 2022
C++ client library for PostgreSQL

Welcome to taoPQ taoPQ is a lightweight C++ client library for accessing a PostgreSQL➚ database. It has no dependencies beyond libpq➚, the C applicati

The Art of C++ 213 Jun 22, 2022
Backup / restore solution for PostgreSQL

pgmoneta pgmoneta is a backup / restore solution for PostgreSQL. pgmoneta is named after the Roman Goddess of Memory. Features Full backup Restore Sym

null 35 Jun 22, 2022
recovery postgresql table data by update/delete/rollback/dropcolumn command

recovery postgresql table data by update/delete/rollback/dropcolumn command

RadonDB 4 Mar 30, 2022
xxhash functions for PostgreSQL

pg_xxhash PostgreSQL ❤️ xxhash Tested with xxhash 0.8.1 and PostgreSQL 14.1 on Linux and macOS. Think twice before even considering to use it in any s

Igor Hatarist 5 Mar 11, 2022
Distributed PostgreSQL as an extension

What is Citus? Citus is a PostgreSQL extension that transforms Postgres into a distributed database—so you can achieve high performance at any scale.

Citus Data 6.8k Jun 28, 2022
Reliable PostgreSQL Backup & Restore

pgBackRest Reliable PostgreSQL Backup & Restore Introduction pgBackRest aims to be a reliable, easy-to-use backup and restore solution that can seamle

pgBackRest 1.2k Jun 25, 2022
upstream module that allows nginx to communicate directly with PostgreSQL database.

About ngx_postgres is an upstream module that allows nginx to communicate directly with PostgreSQL database. Configuration directives postgres_server

RekGRpth 1 Apr 29, 2022
Modern cryptography for PostgreSQL using libsodium.

pgsodium pgsodium is an encryption library extension for PostgreSQL using the libsodium library for high level cryptographic algorithms. pgsodium can

Michel Pelletier 252 May 17, 2022