DOC TIP on pg_ctl and wal_keep_segments

[T.Anastacio]

What happened?

On official documentation https://patroni.readthedocs.io/en/latest/patroni_configuration.html
there is lists of arguments that patroni pass to pg_ctl command to get the highest priority

All parameters from these lists are:

max_connections: 100
max_locks_per_transaction: 64
max_worker_processes: 8
max_prepared_transactions: 0
wal_level: hot_standby
track_commit_timestamp: off
max_wal_senders: 5
max_replication_slots: 5
wal_keep_segments: 8 (replaced by wal_keep_size: 128MB from PG13)
listen_addresses
port
cluster_name
hot_standby: on
wal_log_hints: on

The issue is:
I see no parameter wal_keep_size passed to pg_ctl command.

patronictl version 3.2.2
postgres 16.2 distribution for centos distribs.

/usr/pgsql-16/bin/postgres -D /pgsqldata/data/pg_data --config-file=/pgsqldata/data/pg_data/postgresql.conf --listen_addresses=0.0.0.0 --port=5432 --cluster_name=applitest1 --wal_level=logical --hot_standby=on --max_connections=100 --max_wal_senders=10 --max_prepared_transactions=0 --max_locks_per_transaction=64 --track_commit_timestamp=off --max_replication_slots=10 --max_worker_processes=8 --wal_log_hints=on

How can we reproduce it (as minimally and precisely as possible)?

Starting a patroni cluster with any configuration

What did you expect to happen?

pg_ctl should call parameter wal_keep_size

from a DBA and a ansible admin point of view , it is not that bad if wal_keep_size is not called by pg_ctl , a documentatio update should be enough

Patroni/PostgreSQL/DCS version

• Patroni version: 3.2.2
• PostgreSQL version: 16
• DCS (and its version):
  etcd 3.2.x

Patroni configuration file

---
scope: applitest1
name: l203eb2009
#namespace default to scope, it is a good start
#namespace:

log:
  # Log's In memory queue size
  #1000 equals to 1h20 of logs, so 10000 to 13h20
  #max_queue_size: 10000
  dir: /pgsqldata/logs/patroni
    #  level: DEBUG
    #traceback_level: DEBUG


restapi:
  listen: l203eb2009:8008
  connect_address: l203eb2009:8008

etcd3:
  host: l203eb2009:2379


bootstrap:

  dcs:
   #loop_wait + 2 * retry_timeout <= ttl
   ttl: 30
   loop_wait: 10
   retry_timeout: 10
   maximum_lag_on_failover: 1048576
     #   synchronous_mode:
   failsafe_mode: true
   postgresql:
     #use_pg_rewind: true
     #Slots should be disabled if pgbackrest is in use
     #use_slots: true
     parameters:
       wal_level: logical


#Following sections do not apply if postgres already exists

  method: initdb
  initdb:
    - data-checksums
    - encoding: UTF8
    - locale: en_US.utf8
    - username: postgres

  #bootstrap.user section will be remove from v4.0.0
  #users:

postgresql:
  listen: 0.0.0.0:5432
  connect_address: l203eb2009:5432
  data_dir: /pgsqldata/data/pg_data
  bin_dir: /usr/pgsql-16/bin
  pgpass: /home/postgres/.patronipgpass
  authentication:
    replication:
      username: rep_user
        #password: newpass
        #    superuser:
        #username: postgres
        #password: newpass
        #create_replica_methods:
        #- pgbackrest
        #pgbackrest:
        #command: /usr/bin/pgbackrest --stanza=<scope> --delta --repo=1 restore
        #keep_data: True
        #no_params: True
  #Example to manage postgresql parameters
  #parameters:
  # log_directory: /pgsqldata/data/pg_data/log

patronictl show-config

patronictl show-config
failsafe_mode: true
loop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
  parameters:
    wal_level: logical
retry_timeout: 10
ttl: 30

Patroni log files

2024-04-10 17:32:13,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:32:23,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:32:33,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:32:43,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:32:53,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:03,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:13,597 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:23,681 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:33,681 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:43,596 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:33:53,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:03,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:13,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:23,596 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:33,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:43,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:34:53,595 INFO: no action. I am (l203eb2009), the leader with the lock
2024-04-10 17:35:03,595 INFO: no action. I am (l203eb2009), the leader with the lock

PostgreSQL log files

2024-04-10 17:28:13.236 CEST [277370] LOG:  starting PostgreSQL 16.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2), 64-bit
2024-04-10 17:28:13.236 CEST [277370] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-04-10 17:28:13.238 CEST [277370] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2024-04-10 17:28:13.240 CEST [277370] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2024-04-10 17:28:13.246 CEST [277375] LOG:  database system was shut down at 2024-04-10 17:28:12 CEST
2024-04-10 17:28:13.251 CEST [277370] LOG:  database system is ready to accept connections
2024-04-10 17:33:13.634 CEST [277372] LOG:  checkpoint starting: time
2024-04-10 17:33:18.250 CEST [277372] LOG:  checkpoint complete: wrote 49 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycle

Have you tried to use GitHub issue search?

• Yes

Anything else we need to know?

No response

[Alexander Kukushkin]

The issue is:
I see no parameter wal_keep_size passed to pg_ctl command.

wal_keep_size doesn't require postgres restart, therefore it is not used as a command line argument in order to be able to change it without interruptions.

For the future - please use Slack for questions!