PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Réplication » Pb de création du serveur de backup (syntax error in history file) » 24/03/2023 12:14:05

Ok, mais que me conseillez vous ?
Il y a-t-il une documentation pour gérer le contenu de ce fichier .history en version 14 ?

#2 Re : Réplication » Pb de création du serveur de backup (syntax error in history file) » 23/03/2023 10:36:35

Bonjour,

Désolé si je n'ai pas été assez précis au niveau du renseignement des serveurs sur lesquels j'ai lancé mes commandes et consulté mes logs. J'ai modifié mon 1er message en y ajoutant plus de détails.
Je remarque que les erreurs ont été tracées dans les logs du serveur master (pas de traces ds les logs du serveur de backup)
L'erreur est la suivante :

2023-03-23 09:25:36.498 CET,"replication","",609470,"<IP>:46332",641c0ce4.94cbe,69,"sending backup ""pg_basebackup base backup""",2023-03-23 09:25:08 CET,34/0,0,FATAL,XX000,"syntax error in history file: 171/C1000078

Pour information, je n'ai pas vraiment généré le contenu fichier 00000003.history de manière aléatoire, j'ai suivi la procédure décrite ici https://superuser.com/questions/1127360 … on-working (en adaptant une commande de la version 9.6 en version 14). Cette technique de résolution avait marché plusieurs fois sur une autre installation PGSQL en version 9.6.

Je reste à votre disposition pour toute question/remarque et vous remercie d'avance pour vos retours.

#3 Réplication » Pb de création du serveur de backup (syntax error in history file) » 22/03/2023 19:10:01

Imagin0s
Réponses : 5

Bonjour,
Je suis actuellement en train d'installer un serveur de backup en version PGSQL 14.1.
Le but est d'avoir deux noeux de BDD . Un noeud master et un noeud backup en mode "hot standby"
Le serveur master est Up & running mais je ne parviens pas à créer la BDD sur le serveur de backup à partir du serveur master via la commande pg_basebackup.


Après lancement de la commande sur le serveur backup:

pg_basebackup -h <serveur master> -U replication -D /<chemin d'install>/postgres/data/14_1/db -P --write-recovery-conf --wal-method=fetch --waldir=/<chemin d'install>/postgres/backup/14_1/current_xlog

Le PGSQL du serveur de backup ne démarre pas.
J'ai consulté les logs d'erreur PGSQL du serveur de master et a trouvé l'erreur :

ERROR: could not open file "pg_wal/00000003.history": No such file or directory

Je me suis alors connecté à la BDD du serveur de master et j'ai lancé :

select pg_current_wal_lsn();

J'ai ensuite copié le résultat sur le serveur de backup dans un fichier /<chemin d'install>/backup/14_1/current_xlog/00000003.history

J'ai ensuite relancé la commande pg_basebackup sur le serveur de backup :

pg_basebackup -h <serveur master> -U replication -D /<chemin d'install>/postgres/data/14_1/db -P --write-recovery-conf --wal-method=fetch --waldir=/<chemin d'install>/postgres/backup/14_1/current_xlog

et obtiens l'output suivant :

pg_basebackup: error: could not get COPY data stream: FATAL:  syntax error in history file: 171/C1000078

HINT:  Expected a write-ahead log switchpoint location.
pg_basebackup: removing contents of data directory "/<chemin d'install>/data/14_1/db"
pg_basebackup: removing contents of WAL directory "/<chemin d'install>/backup/14_1/current_xlog"

Pour information, j'ai testé en alimentant le contenu du fichier du serveur de backup /<chemin d'install>/backup/14_1/current_xlog/00000003.history de 2 manières différentes :
1) Avec le résultat de la commande : select pg_current_wal_lsn() du serveur master
2) Et celui de : SELECT pg_switch_wal();  du serveur master

Merci d'avance pour vos retours.
Cordialement.

#4 Re : Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 19/11/2021 15:15:41

Bonjour @gleu,

Oui, j'ai résolu ce soucis en utilisant la méthode 1. en tant que user postgres (car pas possible de renommer le user de la session active)

Pour info, suite à 5/6 problèmes à résoudre en utilisant la méthode pg_upgrade, j'ai laissé tomber et je me suis dirigé vers la méthode "18.6.1. Upgrading Data via pg_dumpall"
Ca a l'air de mieux marcher.

Par contre, je n'ai pas l'étape "Post-upgrade processing" (cf. cette doc : https://www.postgresql.org/docs/13/pgupgrade.html) qui me semble utile.
Cette étape a-t-elle une utilité ds notre cas présent ?

Merci d'avance.
Cordialement.

#5 Re : Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 17/11/2021 14:42:37

Après quelques recherches, j'ai trouvé un sujet sur un autre forum qui indique que l'install user est celui avec un OID de 10 (cf. https://issueexplorer.com/issue/zalando/spilo/602)
En listant l'ensemble de mes rôles sur le base postgres 9.6 d'origine, j'obtiens ceci :

postgres=# SELECT * FROM pg_roles;
             rolname              | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcanlogin | rolreplication | rolconnlimit | rolpassword | rolvaliduntil | rolbypassrls | rolconfig |  oid
----------------------------------+----------+------------+---------------+-------------+-------------+----------------+--------------+-------------+---------------+--------------+-----------+-------
 pg_signal_backend                | f        | t          | f             | f           | f           | f              |           -1 | ********    |               | f            |           |  4200
 cbe5b6d305d0d2393a438cb6d8efb534 | t        | t          | t             | t           | t           | t              |           -1 | ********    |               | t            |           |    10
 postgres_artifactory             | t        | t          | t             | t           | t           | t              |           -1 | ********    |               | t            |           | 16385
 replication                      | f        | t          | f             | f           | t           | t              |           -1 | ********    |               | f            |           | 16384
 artifactory                      | f        | t          | f             | f           | t           | f              |           -1 | ********    |               | f            |           | 16387
 admin_pgsql                      | f        | t          | t             | t           | t           | f              |           -1 | ********    |               | f            |           | 16386
 postgres                         | t        | t          | t             | t           | t           | t              |           -1 | ********    |               | t            |           | 16388
 xray                             | f        | t          | f             | f           | t           | f              |           -1 | ********    |               | f            |           | 24629
 artifactory_tower                | f        | t          | f             | f           | t           | f              |           -1 | ********    |               | f            |           | 36418
(9 rows)

Le 2ème rôle " cbe5b6d305d0d2393a438cb6d8efb534" a l'OID 10. Je me demande s'il faut le renommer en postgres_artifactory (si c'est possible d'avoir un doublon) ou bien attribuer l'OID 10 à mon userpostgres_artifactory.
Aurez-vous une suggestion ? J'aimerai éviter de tout casser.

Cdt.

#6 Re : Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 17/11/2021 11:08:54

Voici la commande qui a été lancée pour initier la DB postgres en 9.6 :

su - postgres_artifactory
/usr/pgsql-9.6/bin/initdb --pgdata=/applis/24140-tdgg/artifactory/postgres/data/9.6/db --xlogdir=/applis/24140-tdgg/artifactory/postgres/backup/9.6/current_xlog -E 'UTF-8' --lc-collate='en_GB.UTF-8' --lc-ctype='en_GB.UTF-8' -U postgres_artifactory -W

J'ai essayé de refaire le pg_upgrade en ajoutant -U postgres :
/usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db -U postgres
mais nous avons la même erreur :

...
database user "postgres" is not the install user
Failure, exiting
"/usr/pgsql-9.6/bin/pg_ctl" -w -D "/applis/24140-tdgg/artifactory/postgres/data/9.6/db" -o "" -m fast stop >> "pg_upgrade_server.log" 2>&1

#7 Re : Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 17/11/2021 10:45:51

J'ai démarré le service de postgres 9.6 pour me connecter à la DB et lister les rôles et j'ai ce résultat :

[postgres_artifactory@xxxxxxxxxxx ~]$ psql -d postgres
psql (13.4, server 9.6.11)
Type "help" for help.

postgres=# \du
                                               List of roles
            Role name             |                         Attributes                         | Member of
----------------------------------+------------------------------------------------------------+-----------
 admin_pgsql                      | Create role, Create DB                                     | {}
 artifactory                      |                                                            | {}
 artifactory_tower                |                                                            | {}
 cbe5b6d305d0d2393a438cb6d8efb534 | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 postgres                         | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 postgres_artifactory             | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 replication                      | Replication                                                | {}
 xray                             |                                                            | {}

J'ai également démarré le service de postgres 13.4 mais lorsque j'essaie de me connecter à la DB j'ai cette erreur :

root@xxxxxxxxxxx:/etc/systemd/system$ psql -d postgres
psql: error: FATAL:  role "root" does not exist

Je n'ai rien créée en terme de rôle sur la nouvelle instance en 13.4, juste lancé un initdb. Etant donné que l'ancienne instance a été créée avec un user non standard "postgres_artifactory", voulez-vous dire qu'il faut que je créée également ce rôle dans la nouvelle instance avant de lancer le pg_upgrade ?
Comment puis-je le faire ?

Merci d'avance.

Cdt.

#8 Re : Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 17/11/2021 09:47:22

Bonjour,

@rjuju : Oui, j'ai vérifié l'existence des fichiers/répertoires

@gleu : En effet, c'est un soucis de copier-coller. Le bash ne doit pas être top, j'ai fait un CC à partir de la commande de l'history bash et il y a du y avoir des caractères mal traduits.
Je viens de relancer la commande, ça a avancé mais j'ai cette erreur maintenant :

[postgres_artifactory@sxxxxxxxxxx ~]$ /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db

...

executing: SELECT pg_catalog.set_config('search_path', '', false);
Checking database user is the install user                  executing: SELECT rolsuper, oid FROM pg_catalog.pg_roles WHERE rolname = current_user AND rolname !~ '^pg_'

database user "postgres_artifactory" is not the install user
Failure, exiting
"/usr/pgsql-9.6/bin/pg_ctl" -w -D "/applis/24140-tdgg/artifactory/postgres/data/9.6/db" -o "" -m fast stop >> "pg_upgrade_server.log" 2>&1

Pourtant, j'ai bien fait l'initdb du cluster d'origine version 9.6 et du cluster cible 13.4 avec le user postgres_artifactory.

Merci d'avance.
Cdt.

#9 Installation » Upgrade postgres 9.6 => 13.4 : pg_upgrade : No such file or directory » 17/11/2021 02:29:00

Imagin0s
Réponses : 11

Bonjour,

Je suis en train d'upgrader de Postgres 9.6 vers Postgres 13.4.
J'ai bien lancé l'étape init_db, mais j'ai une erreur "No such file or directory" lors de la phase pg_upgrade :

[postgres_artifactory@sxxxxxxxxxx bin]$ /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db
bash: /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db: No such file or directory

C'est étrange car tous les répertoires utilisés en valeur des options existent bien :
/usr/pgsql-9.6/bin
/usr/pgsql-13/bin
/applis/24140-tdgg/artifactory/postgres/data/9.6/db
/applis/24140-tdgg/artifactory/postgres/data/13.4/db

Auriez-vous une idée SVP ?
Si vous avez des questions/remarques, n'hésitez pas.

Merci d'avance.

Cdt.

#10 Re : Installation » Upgrade de postgres de 9.6.11 => 13.4 » 27/10/2021 09:44:35

Bonjour,
Merci gleu pour ta réponse et désolé pour la réponse tardive.
Pour le produit Artifactory, je pense que cela peut être potentiellement intéressant car l'index est régulièrement mis-à-jour. Il y a d'ailleurs un système de Garbage collector qui tourne régulièrement pour supprimer les artifacts non indexés.
Aurais-tu STP un lien vers un document ou une procédure pour effectuer cette action ?
Pour rappel nous souhaiterions directement upgrader de postgres 9.6 vers 13.4.3
Merci d'avance

#11 Re : Installation » Upgrade de postgres de 9.6.11 => 13.4 » 11/10/2021 10:47:26

Bonjour,

@gleu : Merci pour ton retour. Je pose la question également pour savoir si il y a des bonnes pratiques à respecter pour améliorer les performances après upgrade.
Par exemple, dans cette doc, j'ai lu qu'il était conseillé de "rebuild your B-tree indexes" après upgrade vers postgres 12:
https://blog.crunchydata.com/blog/just- … erformance

Cordialement.

#12 Re : Installation » Upgrade de postgres de 9.6.11 => 13.4 » 08/10/2021 17:22:19

Bonjour,
Merci pour votre réponse.
1. C'est du streaming simple.
2. Nous pouvons arrêter notre instance deux heures environ je dirais durant les heures non ouvrées. L'arrêt durera au moins une heure vu que nous souhaitons figer et backuper les données de la base avant intervention et le backup en lui-même dure 1h via pg_basebackup
3. Actuellement les data de notre BDD postgres occupe 415G
Cordialement.

#13 Re : Installation » Upgrade de postgres de 9.6.11 => 13.4 » 07/10/2021 10:43:02

Hello,
Je voulais dire que Postgres est installé en mode Master/slave avec 1 Master et 1 Slave.
Cordialement

#14 Installation » Upgrade de postgres de 9.6.11 => 13.4 » 06/10/2021 18:21:34

Imagin0s
Réponses : 10

Bonjour,

Afin d'améliorer la performance du traitement des requêtes et des webrequests sur mon Artifactory et Xray de production, je souhaiterai upgrader la BDD Postgres de la version 9.6.11 vers la version 13.4.

J'ai lu les Release notes des major versions 10, 11, 12 et 13 et a constaté certains changements à avoir en tête lors de l'upgrade.
Voici une liste non exhaustive que j'ai constituée :
- le renommage du répertoire pg_xlog en pg_wal (depuis la version majeure 10)
- renommage de la fonction SQL pg_switch_xlog() en pg_switch_wall()  (depuis la version majeure 10)
- déplacement du contenu du recovery.conf dans postgresql?conf (depuis la version majeure 12)
- renommage du paramètre wal_keep_segments en wal_keep_size (depuis la version majeure 13)

Je compte utiliser cette procédure :
https://www.postgresql.org/docs/13/upgrading.html pour faire l'upgrade (en utilisant pg_upgrade)

Sachant que notre installation de Postgres en production est en mode cluster, auriez-vous des préconisations afin que cet upgrade se passe sans régression ou incident ?

Merci d'avance.
Cordialement.

#15 Re : Réplication » Archive logs se remplissent trop vite et pg_xlog pas assez » 03/08/2021 20:15:54

@gleu :
Je vais suivre ton conseil et ajouter cette config ds le fichier recovery.conf :

archive_cleanup_command = 'pg_archivecleanup emplacementarchive %r'

Je surveille la purge et les métriques sur l'occupation du filesystem et vous tiens au courant.
Merci.

@rjuju :
Désolé de répondre seulement maintenant à ta réponse du 29/07 mais je n'avais pas compris.
Que veux tu dire par "copie pas atomique" ? Est-ce que tu veux dire qu'il est possible de manquer des fichiers lors de la copie (d'où l'intérêt d'utiliser rsync qui fait une copie incrémentale du contenu des répertoires) ?
Ps compris non plus la nécessité de forcer un fsync, c'est fait à fréquence régulière par l'OS de mémoire

#16 Re : Réplication » Archive logs se remplissent trop vite et pg_xlog pas assez » 02/08/2021 17:48:25

Désolé pour la réponse tardive.

En relisant le code de notre script de purge, je me rends compte qu'il utilisait déjà la commande pg_archivecleanup.
Le script est schedulé pour être lancé deux fois par jour par le crontab Linux.

Ci-dessous les lignes correspondantes du script :

OUTPUT=`find ${DIR_BACKUP} -type f -name "0000000*" -mtime ${RETENTION} -print | tail -n1`
# Purge des anciens WALs
WAL=`basename ${OUTPUT}`
# PATH de pg_archivecleanup
ARCHIVECLEANUP=$(locate pg_archivecleanup | head -1)
eval ${ARCHIVECLEANUP} -d ${DIR_BACKUP} ${WAL} >${LOG_ARCH_CLEAN} 2>&1

J'ai l'impression que cela revient au même que faire une purge des fichiers plus vieux qu'une durée de rétention donnée.
Pourriez-vous SVP m'indiquer quelle commande lancer pour que le secondaire ne garde que les logs "dont il a besoin" (à savoir non écrites en base si j'ai bien compris) ?

Merci d'avance.

#17 Re : Réplication » Archive logs se remplissent trop vite et pg_xlog pas assez » 29/07/2021 20:30:01

Bonjour,
Merci pour vos retours

Pour info, le FS des archive logs est monté sur un partage NFS partagé par le serveur primaire et secondaire.
xxxxxx.fr.net.intra:/vol_SVM_DMZ_MULTI_PROD_063/yyyy_qtree  260G  216G   45G  83% /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs

Je ne comprends pas ce concept de journal "plein". Pourriez-vous SVP m'expliquer les critères possibles de déclenchement de la copie des logs ds pg_xlog vers le répertoire d'archive logs ?
Nous avons essayé d'augmenter la valeur de "wal_keep_segments" afin de garder les pg_xlog plus longtemps avant copie vers le répertoire d'archive logs, sans succés.

Concernant l'utilisation de pg_archivecleanup, je me suis renseigné sur le lien officiel et je ne suis pas sûr qu'il réponde à notre besoin.
Nous souhaitons conserver les archive logs sur plusieurs jours pour répondre au cas par exemple où le serveur secondaire est indisponible pendant plusieurs jours (crash de la VM, soucis de réplication etc.) afin de pouvoir faire une restauration des transactions jouées sur le noeud primaire en l'absence du noeud secondaire une fois que celui-ci est de nouveau rendu disponible.
Nous avons mis en place un script de purge ds le contab qui purge les archives logs de plus de 4 jours.

Merci.
Cdt.

#18 Re : Réplication » Archive logs se remplissent trop vite et pg_xlog pas assez » 29/07/2021 09:43:14

Bonjour,

Voici la configuration des WAL redo logs extraite du fichier de configuration postgresql.conf :

------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------

# - Settings -

wal_level = replica                     # minimal, replica, or logical
                                        # (change requires restart)
fsync = on                              # flush data to disk for crash safety
                                                # (turning this off can cause
                                                # unrecoverable data corruption)
synchronous_commit = local              # synchronization level;
                                        # off, local, remote_write, remote_apply, or on
#wal_sync_method = fsync                # the default is the first option
                                        # supported by the operating system:
                                        #   open_datasync
                                        #   fdatasync (default on Linux)
                                        #   fsync
                                        #   fsync_writethrough
                                        #   open_sync
#full_page_writes = on                  # recover from partial page writes
#wal_compression = off                  # enable compression of full-page writes
#wal_log_hints = off                    # also do full page writes of non-critical updates
                                        # (change requires restart)
wal_buffers = 16MB                      # min 32kB, -1 sets based on shared_buffers
                                        # (change requires restart)
#wal_writer_delay = 200ms               # 1-10000 milliseconds
#wal_writer_flush_after = 1MB           # measured in pages, 0 disables

#commit_delay = 0                       # range 0-100000, in microseconds
#commit_siblings = 5                    # range 1-1000

# - Checkpoints -

checkpoint_timeout = 5min               # range 30s-1d
max_wal_size = 4GB
min_wal_size = 2GB
#checkpoint_completion_target = 0.5     # checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB         # measured in pages, 0 disables
#checkpoint_warning = 30s               # 0 disables

# - Archiving -

archive_mode = on               # enables archiving; off, on, or always
                                # (change requires restart)
archive_command = 'cp %p /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs/%f'            # command to use to archive a logfile segment
                                # placeholders: %p = path of file to archive
                                #               %f = file name only
                                # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
archive_timeout = 3600          # force a logfile segment switch after this
                                # number of seconds; 0 disables

------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication data.

max_wal_senders = 10            # max number of walsender processes
                                # (change requires restart)
wal_keep_segments = 500
#wal_keep_segments = 25         # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s       # in milliseconds; 0 disables

max_replication_slots = 1 # max number of replication slots
                                # (change requires restart)
#track_commit_timestamp = off   # collect timestamp of transaction commit
                                # (change requires restart)

# - Master Server -

# These settings are ignored on a standby server.

synchronous_standby_names = 'walreceiver'       # standby servers that provide sync rep
                                # number of sync standbys and comma-separated list of application_name
                                # from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is delayed

# - Standby Servers -

# These settings are ignored on a master server.

hot_standby = on                        # "on" allows queries during recovery
                                        # (change requires restart)
#max_standby_archive_delay = 30s        # max delay before canceling queries
                                        # when reading WAL from archive;
                                        # -1 allows indefinite delay
#max_standby_streaming_delay = 30s      # max delay before canceling queries
                                        # when reading streaming WAL;
                                        # -1 allows indefinite delay
#wal_receiver_status_interval = 10s     # send replies at least this often
                                        # 0 disables
#hot_standby_feedback = off             # send info from standby to prevent
                                        # query conflicts
#wal_receiver_timeout = 60s             # time that receiver waits for
                                        # communication from master
                                        # in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s       # time to wait before retrying to
                                        # retrieve WAL after a failed attempt


#------------------------------------------------------------------------------

Cordialement.

#19 Réplication » Archive logs se remplissent trop vite et pg_xlog pas assez » 28/07/2021 16:50:17

Imagin0s
Réponses : 11

Bonjour,

Je rencontre un soucis sur mon serveur postgres de production (version : 9.6).
Pour info, ce serveur est master dans une architecture master/slave avec streaming des logs de transactions
Le soucis est que le filesystem des wal redo logs archivés (archive_logs) se remplit trop rapidement tandis que le FS des wal redo logs (pg_xlog) stagne.

Actuellement, mes FS sont utilisés comme suit :
/dev/mapper/vg_apps-lv_pgsql96_backup                                    208G  9.1G  190G   5% /applis/24140-tdgg/artifactory/postgres/backup/9.6
xxxxxx.fr.net.intra:/vol_SVM_DMZ_MULTI_PROD_063/yyyy_qtree  260G  216G   45G  83% /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs

Comme vous pouvez le voir le FS des archive_logs est surutilisé (216/260G) tandis que le FS des pg_xlog est sous-utilisé (9.1/208G)

Sauriez-vous comment faire ne sorte que les logs soient conservés plus longtemps ds le FS des pg_xlog afin d'éviter la saturation permanente du FS des archive logs ?

Merci d'avance pour votre réponse.
Cordialement.

Pied de page des forums

Propulsé par FluxBB