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 : Général » Err Syntaxe REINDEX VERBOSE » 19/02/2019 09:32:38

Bonjour et merci Guillaume, je ne devais pas avoir les yeux en face des trous hier, désolé.

#2 Général » Err Syntaxe REINDEX VERBOSE » 18/02/2019 10:13:34

mortimer.pw
Réponses : 2

Bonjour à tous,

Je travaille avec un moteur 10.3 sous Cent-OS 7.5.

J'essaye d'exécuter la commande REINDEX avec l'option VERBOSE et j'ai un message d'erreur de syntaxe.

J'ai essayé plusieurs commandes :
geo=# reindex (verbose) geo.type_of;
ERROR:  syntax error at or near "geo"
LINE 1: reindex (verbose) geo.type_of;
                          ^
geo=# reindex (verbose) type_of;
ERROR:  syntax error at or near "type_of"
LINE 1: reindex (verbose) type_of;
                          ^
geo=# reindex verbose type_of;
ERROR:  syntax error at or near "verbose"
LINE 1: reindex verbose type_of;
                ^
geo=# \d geo.type_of;
                         Table "geo.type_of"
   Column   |         Type          | Collation | Nullable | Default
------------+-----------------------+-----------+----------+---------
id_cgu     | character varying(20) |           | not null |
id_type_of | character varying(2)  |           | not null |
libelle    | character varying(30) |           | not null |
type       | numeric               |           | not null | 0
date_susp  | date                  |           |          |
Indexes:
    "pk_type_of" PRIMARY KEY, btree (id_cgu, id_type_of)
Foreign-key constraints:
    "fk_type_of_cgu" FOREIGN KEY (id_cgu) REFERENCES cgu(id_cgu)
Referenced by:
    TABLE "demandeur" CONSTRAINT "fk_demandeur_type_of" FOREIGN KEY (id_cgu, id_type_of) REFERENCES type_of(id_cgu, id_type_of)
    TABLE "info_creation_commande" CONSTRAINT "fk_info_creation_commande_type_of" FOREIGN KEY (id_cgu, id_type_of) REFERENCES type_of(id_cgu, id_type_of)
    TABLE "sygesst.info_creation_commande" CONSTRAINT "fk_info_creation_commande_type_of" FOREIGN KEY (id_cgu, id_type_of) REFERENCES type_of(id_cgu, id_type_of)
    TABLE "o_f" CONSTRAINT "fk_o_f_type_of" FOREIGN KEY (id_cgu, id_type_of) REFERENCES type_of(id_cgu, id_type_of)

Je ne vois pas d'où peut venir l'erreur.

Pouvez-vous m'aider svp ?

#3 Re : Optimisation » Fragmentation des tables et indexes » 30/11/2018 09:18:45

Bonjour Guillaume.
Ok, merci pour les explications.
Bon week-end.

#4 Re : Optimisation » Fragmentation des tables et indexes » 28/11/2018 12:48:17

Bonjour Guillaume,
Merci d'avoir pris le temps d'apporter des réponses à mes questions.
Du coup, j'ai une autre interrogation, je pensais avoir lu que dans les fonctionnalités du Vacuum, il y avait le nettoyage des indexes ?
C'est juste "un marquage" des lignes plus utilisées ? La réindexation doit être déclenchée manuellement ?

#6 Optimisation » Fragmentation des tables et indexes » 19/11/2018 13:24:26

mortimer.pw
Réponses : 10

Bonjour à tous,

Je travaille avec un moteur 10.3 sous Cent-OS 7.5.

Je souhaite surveiller la fragmentation des tables et indexes "sensibles" de notre application.

J'ai mis en place l'extension PGSTATTUPLE.

J'ai trouvé la requête ci-dessous sur le sujet :

SELECT pn.nspname AS SCHEMA,pc2.relname AS TABLE,PG_SIZE_PRETTY(PG_RELATION_SIZE(pn.nspname||'.'||pc2.relname))AS TBL_SIZE,dead_tuple_percent AS PCT_DEAD_LINE,
pc.relname AS INDEX,PG_SIZE_PRETTY(index_size) AS INDEX_SIZE,leaf_pages AS NB_LEAF,empty_pages AS EMPT_LEAF,deleted_pages AS DEL_LEAF,avg_leaf_density AS LEAF_DENS,leaf_fragmentation AS FRAG_LEAF
FROM pg_class pc,pg_class pc2,pg_index pi,pg_namespace pn,
PGSTATTUPLE(pc2.oid),PGSTATINDEX(pn.nspname||'.'||pc.relname)
WHERE pc.relkind='i'
AND pc.oid=pi.indexrelid
AND pi.indrelid=pc2.oid
AND pc.relnamespace=pn.oid
AND pn.nspname||'.'||pc2.relname IN('go.table1')
ORDER BY pn.nspname,pc2.relname,pc.relname;

Je l'ai exécuté sur une première table :

schema |    table     | tbl_size | pct_dead_line |              index               | index_size | nb_leaf | empt_leaf | del_leaf | leaf_dens | frag_leaf
-------+--------------+----------+---------------+----------------------------------+------------+---------+-----------+----------+-----------+-----------
go    |  table1      | 616 MB   |          2.16 | pk_table1                        | 1088 MB    |  103738 |         0 |    32743 |     54.05 |     14.04

J'ai ensuite regardé les stats sur la table :

go=# select * from pg_stat_all_tables where schemaname='go' and relname in ('table1');

relid | schemaname |   relname    | seq_scan | seq_tup_read | idx_scan  | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | n_mod_since_analyze | last_vacuum |        last_autovacuum
       | last_analyze |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count
-------+------------+--------------+----------+--------------+-----------+---------------+-----------+-----------+-----------+---------------+------------+------------+---------------------+-------------+------------------------
-------+--------------+-------------------------------+--------------+------------------+---------------+-------------------
16853 |  go        |   table1     |      201 |    549632316 |       117 |           115 |   1505074 |         0 |   1432601 |             0 |    4177689 |     282570 |              114490 |             | 2018-11-12 06:01:53.281
133+03 |              | 2018-11-17 06:00:12.75971+03  |            0 |                2 |             0 |                 6

J'ai fait un Vacuum :

go=# vacuum (full, verbose, analyze) go.table1;
INFO:  vacuuming "go.table1"
INFO:  "table1": found 123447 removable, 4457080 nonremovable row versions in 78860 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU: user: 2.85 s, system: 1.26 s, elapsed: 5.71 s.
INFO:  analyzing "go.table1"
INFO:  "table1": scanned 30000 of 63469 pages, containing 2107178 live rows and 0 dead rows; 30000 rows in sample, 4457522 estimated total rows
VACUUM

J'ai regardé à nouveau les stats :

go=# select * from pg_stat_all_tables where schemaname='go' and relname in ('table1');

relid | schemaname |   relname    | seq_scan | seq_tup_read | idx_scan  | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | n_mod_since_analyze | last_vacuum |        last_autovacuum
       | last_analyze |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count
-------+------------+--------------+----------+--------------+-----------+---------------+-----------+-----------+-----------+---------------+------------+------------+---------------------+-------------+------------------------
-------+--------------+-------------------------------+--------------+------------------+---------------+-------------------
16853 |  go        |   table1     |      203 |    558669923 |       117 |           115 |   1505074 |         0 |   1432601 |             0 |    4457522 |          0 |                   0 |             | 2018-11-12 06:01:53.281
133+03 | 2018-11-19 13:39:05.076427+03 | 2018-11-17 06:00:12.75971+03  |            0 |                2 |             1 |                 6

Et j'ai regardé à nouveau la fragmentation :

schema |    table     | tbl_size | pct_dead_line |              index               | index_size | nb_leaf | empt_leaf | del_leaf | leaf_dens | frag_leaf
--------+--------------+----------+---------------+----------------------------------+------------+---------+-----------+----------+-----------+-----------
go     |  table1      | 496 MB   |             0 | pk_table1                        | 458 MB     |   57568 |         0 |        0 |     90.76 |         0


Pour la fragmentation des tables, est-ce bien lorsque le PCT_DEAD_LINE dépasse un certain seuil qu'il faut décider d'un vacuum full sur la table ?
Pour les indexes, est-ce bien en fonction des LEAF_DENS et FRAG_LEAF ?

J'ai fait un Vacuum Full mais je ne vois pas d'info dans la colonne LAST_VACUUM, est-ce normal ?
J'ai regagné 120 Mo mais un Reindex n'était-il pas plus approprié ? La table était fragmentée à un peu plus de 2% seulement, alors que la densité des feuilles de l'indexe était à 54% ?

Globalement est-ce la bonne démarche ?

D'avance merci pour vos retours.

#7 Re : Général » Tail_n_mail » 13/07/2018 08:46:57

Bonjour,
En ajoutant l'option --debug, j'obtiens les infos suivantes :
perl /home/postgres/scripts/tail_n_mail --dryrun --debug /home/postgres/scripts/tnm.config.txt
Opened config file "/home/postgres/scripts/tnm.config.txt"
$opt1 = {
          'configfile' => {
                            'lastfile' => 1,
                            'file.HASH(0x200b178)' => 1,
                            'file' => 1,
                            'customsubject' => 1,
                            'email' => 1,
                            'email.admin_pg@toto.fr' => 1,
                            'inherit./home/postgres/scripts/lst_include_exclude.txt' => 1,
                            'mailsubject' => 1,
                            'inherit' => 1,
                            'offset' => 1
                          },
          'lastfile' => {
                          '1' => '/home/postgres/pg_log/5-09.log'
                        },
          'file' => [
                      {
                        'lastfile' => '/home/postgres/pg_log/5-09.log',
                        'original' => '/home/postgres/pg_log/%u-%H.log',
                        'suffix' => '1',
                        'name' => '/home/postgres/pg_log/5-09.log',
                        'offset' => '1844263'
                      }
                    ],
          'customsubject' => 1,
          'email' => [
                       'admin_pg@toto.fr'
                     ],
          'mailsubject' => 'Alerte PostgreSQL HOST',
          'inherit' => [
                         '/home/postgres/scripts/lst_include_exclude.txt'
                       ],
          'offset' => {
                        '1' => '1844263'
                      }
        };
$arg1 = {
          'verbose' => 1,
          'log_line_prefix' => '',
          'mailserver' => 'example.com',
          'find_line_number' => 1,
          'file' => [],
          'sortby' => 'count',
          'maxsize' => 80000000,
          'mailuser' => 'example',
          'tsepnosub' => 0,
          'debug' => 1,
          'duration_limit' => 0,
          'sqlstate' => 0,
          'dryrun' => 1,
          'timewarp' => 0,
          'pgmode' => 1,
          'nomail' => 0,
          'canceled_autovac' => 1,
          'duration' => -1,
          'statement_size' => 1000,
          'mailport' => 465,
          'tsep' => undef,
          'flatten' => 1,
          'type' => 'normal',
          'skip_non_parsed' => 0,
          'smtp' => 0,
          'tempfile_limit' => 0,
          'tempfile' => -1,
          'hideflatten' => 1,
          'mailcom' => '/usr/sbin/sendmail',
          'maxemailsize' => 10000000,
          'reset' => 0,
          'pretty_query' => 1,
          'help' => 0,
          'mailmode' => 'sendmail',
          'mailpass' => 'example',
          'offset' => -1,
          'quiet' => 0,
          'showonly' => 0,
          'version' => 0,
          'mailsig' => [],
          'mailzero' => 0,
          'rewind' => 0,
          'pglog' => 'pg'
        };
  Log line prefix regex: (?^:^((\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d \w\w\w\w?) \[(\d+)\])(.*))
  Log line prefix regex2: (?^:^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d \w\w\w\w? \[\d+\])
  Log line prefix regex3: (?^:^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d \w\w\w\w?)
Parsing file: /home/postgres/pg_log/5-09.log
  File: /home/postgres/pg_log/5-09.log Offset: 1,844,263 Size: 1,853,020 Maxsize: 80,000,000
  Adding exclusion: relation " +" does not exist
  Adding exclusion: duplicate key value violates unique constraint "pk_doublon_prod"
  Exclusion: (?^:relation " +" does not exist)|(?^:duplicate key value violates unique constraint "pk_doublon_prod")
  Adding inclusion: WARNING:
  Adding inclusion: ERROR:
  Adding inclusion: FATAL:
  Adding inclusion: PANIC:
  Inclusion: (?^:WARNING:)|(?^:ERROR:)|(?^:FATAL:)|(?^:PANIC:)
  No new lines found in file /home/postgres/pg_log/5-09.log
  Performing final cleanup

#8 Re : Général » User pour Sauvegarde » 11/07/2018 16:34:24

Une pour le vacuum.
Quatre pour les exports (oui pg_dump et pg_dumpall), si long week-end.
Je vais donc réserver 6 superuser_reserved_connections.
Merci.

#9 Re : Général » User pour Sauvegarde » 11/07/2018 15:13:48

Rebonjour,
Guillaume : Je pensais qu'en utilisant un autre User, je préserverais les connexions superuser.
Julien : ok, merci pour l'option.

#10 Général » Tail_n_mail » 11/07/2018 13:23:46

mortimer.pw
Réponses : 2

Bonjour,
Je travaille sur des moteurs entre 9.3 et 10.1 sous Cent-OS 6/7.
J'utilise tail_n_mail, mis en crontab (toutes les minutes), pour surveiller les logs de PostgreSQL et être averti au plus tôt d'un problème.
J'ai mis ça dans mon fichier des INCLUDE/EXCLUDE :
## Fichier des Include_Exclude
INCLUDE: WARNING:
INCLUDE: ERROR:
INCLUDE: FATAL:
INCLUDE: PANIC:
EXCLUDE: relation " +" does not exist
EXCLUDE: duplicate key value violates unique constraint "pk_doublon_prod"
Je n'arrive pas à filtrer, pour ne pas recevoir de mail, sur l'erreur : duplicate key value violates unique constraint "pk_doublon_prod"
Quelle syntaxe utiliser pour ne pas recevoir les alertes sur ce message précis, svp ?

#11 Re : Général » User pour Sauvegarde » 11/07/2018 13:17:39

Bonjour,
Désolé pour la réponse tardive, j'étais sur une urgence.
Le problème c'est que j'utilise le superuser pour mes exports journaliers et mon vacuum hebdomadaire mis en crontab.
Donc si jamais un client lock une table, le vacuum va bloquer, les exports aussi, si c'est pendant un week-end prolongé par exemple, je peux vite arriver à 5-6 connexions utilisées et plus possible d'accéder à la base en rentrant du week-end.
Est-ce la meilleure solution ?
Ne vaut-il mieux pas créer un user avec les droits adéquats pour les exports et vacuum ?

#12 Général » User pour Sauvegarde » 21/06/2018 15:37:27

mortimer.pw
Réponses : 7

Bonjour,
Je travaille sur des moteurs entre 9.3 et 10.1 sous Cent-OS 6/7.
Ce week-end un petit problème avec une BDD (lock sur une table).
En cascade, de nombreux Users bloqués, mon export journalier (pg_dump) et un vacuum full hebdo bloqués.
Lundi matin en arrivant, je veux me connecter à la base pour voir qui bloque et là le drame : FATAL:  sorry, too many clients already
Vilain petit canard que je suis, j'utilise le superuser par défaut pour l'export et le vacuum, superuser_reserved_connections = 3, PAS BIEN.
Je prends donc le sujet au sérieux, j'ai vu sur le net que beaucoup pratique ceci pour un User spécifique sauvegarde :
     CREATE USER backadm SUPERUSER  password '<PASS>';
     ALTER USER backadm set default_transaction_read_only = on;
Est-ce la bonne pratique ?
J'imagine que l'on ne peut pas utiliser le même User pour la restauration ? donc superuser (différent du par défaut) ?
Et même problématique pour le vacuum full ?
D'avance merci pour vos éclaircissements.

#13 Re : Réplication » ERROR: could not find archived wal » 14/02/2018 08:20:15

Bonjour,
Je ne vais malheureusement pas pouvoir rejouer l'instance, je ne conserve (via pitrery) que 3 jours de sauvegarde et le problème est survenu samedi dernier, dommage.
Par contre, je prends bonne note de faire l'archivage en local puis de copier sur le NAS.
Merci à vous pour vos investigations et conseils.

#14 Re : Réplication » ERROR: could not find archived wal » 13/02/2018 09:59:10

Bonjour,
Comme indiqué plus haut, c'est Pitrery qui gère l'archivage.
Nous fonctionnons avec des archives compressées (utilisation de PIGZ).
Les fichiers sont archivés sur un NAS (espace de stockage entre maître et esclave).
Une "micro coupure" réseau peut-elle être à l'origine ?
Si la streaming permet de remédier au problème, tant mieux.
En espérant que la situation ne se détériore pas.
Merci à vous.

#15 Re : Réplication » ERROR: could not find archived wal » 12/02/2018 15:04:10

Voilà le résultat de la commande, après décompression du fichier :
[postgres@dev-postgres-01 ~]$ pg_xlogdump 000000010000007E00000042
rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 7E/42000028, prev 7E/41009E38, desc: RUNNING_XACTS nextXid 350714 latestCompletedXid 350713 oldestRunningXid 350714
rmgr: Heap        len (rec/tot):     65/  6529, tx:     350714, lsn: 7E/42000060, prev 7E/42000028, desc: HOT_UPDATE off 4 xmax 350714 ; new off 5 xmax 0, blkref #0: rel 1663/16384/29662 blk 47 FPW
rmgr: Heap        len (rec/tot):     65/  7753, tx:     350714, lsn: 7E/420019E8, prev 7E/42000060, desc: HOT_UPDATE off 7 xmax 350714 ; new off 8 xmax 0, blkref #0: rel 1663/16384/29662 blk 16 FPW
rmgr: Heap        len (rec/tot):     65/  6685, tx:     350714, lsn: 7E/42003850, prev 7E/420019E8, desc: HOT_UPDATE off 15 xmax 350714 ; new off 14 xmax 0, blkref #0: rel 1663/16384/29662 blk 44 FPW
rmgr: Heap        len (rec/tot):    110/   110, tx:     350714, lsn: 7E/42005288, prev 7E/42003850, desc: HOT_UPDATE off 16 xmax 350714 ; new off 18 xmax 0, blkref #0: rel 1663/16384/29662 blk 44
rmgr: Heap        len (rec/tot):     65/  3397, tx:     350714, lsn: 7E/420052F8, prev 7E/42005288, desc: HOT_UPDATE off 17 xmax 350714 ; new off 18 xmax 0, blkref #0: rel 1663/16384/29662 blk 48 FPW
rmgr: Heap        len (rec/tot):     53/  5449, tx:     350714, lsn: 7E/42006058, prev 7E/420052F8, desc: INPLACE off 44, blkref #0: rel 1663/16384/29723 blk 3 FPW
rmgr: Heap        len (rec/tot):     53/  2201, tx:     350714, lsn: 7E/420075A8, prev 7E/42006058, desc: INPLACE off 2, blkref #0: rel 1663/16384/29723 blk 4 FPW
rmgr: Transaction len (rec/tot):    226/   226, tx:     350714, lsn: 7E/42007E48, prev 7E/420075A8, desc: COMMIT 2018-02-10 03:30:33.730929 CET; inval msgs: catcache 49 catcache 49 catcache 49 catcache 49 catcache 49 catcache 45 catcache 44 catcache 45 catcache 44 relcache 28281 relcache 28286
rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 7E/42007F30, prev 7E/42007E48, desc: RUNNING_XACTS nextXid 350715 latestCompletedXid 350714 oldestRunningXid 350715
rmgr: XLOG        len (rec/tot):     24/    24, tx:          0, lsn: 7E/42007F68, prev 7E/42007F30, desc: SWITCH

#16 Re : Réplication » ERROR: could not find archived wal » 12/02/2018 13:22:51

Bonjour Messieurs,

J'ai extrait quelques infos sur le maître :

SELECT * FROM pg_stat_replication;
  pid  | usesysid | usename  | application_name | client_addr | client_hostname | client_port |         backend_start         | backend_xmin |   state   | sent_location | write_location | flush_location | replay_location | sync_priority
| sync_state
-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+--------------+-----------+---------------+----------------+----------------+-----------------+--------------
-+------------
11668 |       10 | postgres | walreceiver      | 10.71.4.20  |                 |       41542 | 2018-02-10 03:30:20.950022+01 |       351264 | streaming | 80/ED000000   | 80/ED000000    | 80/ED000000    | 80/ED000000     |             0
| async

SELECT * FROM pg_stat_archiver;
archived_count |    last_archived_wal     |      last_archived_time       | failed_count | last_failed_wal | last_failed_time |         stats_reset         
----------------+--------------------------+-------------------------------+--------------+-----------------+------------------+------------------------------
          32522 | 0000000100000080000000EC | 2018-02-12 12:15:33.470238+01 |            0 |                 |                  | 2017-10-24 11:25:51.24938+02
(1 row)

Sur l'esclave :
SELECT * FROM pg_stat_wal_receiver;
  pid  |  status   | receive_start_lsn | receive_start_tli | received_lsn | received_tli |      last_msg_send_time       |     last_msg_receipt_time     | latest_end_lsn |        latest_end_time        | slot_name |                     
                                                 conninfo                                                                       
-------+-----------+-------------------+-------------------+--------------+--------------+-------------------------------+-------------------------------+----------------+-------------------------------+-----------+---------------------
--------------------------------------------------------------------------------------------------------------------------------
29405 | streaming | 7E/42000000       |                 1 | 80/EE000060  |            1 | 2018-02-12 12:21:18.511457+01 | 2018-02-12 12:21:18.489944+01 | 80/EE000060    | 2018-02-12 12:20:48.449176+01 |           | user=postgres passwo
rd=******** dbname=replication host=10.71.4.19 port=5432 fallback_application_name=walreceiver sslmode=disable sslcompression=1
(1 row)

Quelles infos supplémentaires puis-je vous donner ?

#17 Réplication » ERROR: could not find archived wal » 12/02/2018 08:53:56

mortimer.pw
Réponses : 12

Bonjour,
Je travaille sur un moteur 9.6.5 sous Cent-OS 7.3.
J'ai installé la streaming replication.
Pitrery gère mes sauvegardes et WAL.
J'ai ajouté une surveillance des traces via Tail&Mail.
Tout fonctionne correctement depuis quelques semaines.
Dans la nuit de vendredi à samedi, j'ai reçu des mails d'alerte de mon esclave :
        Date: Sat Feb 10 03:30:22 2018 CET
        Host: dev-postgres-02
        Unique items: 3
        Matches from /home/postgres/pg_log/6-03.log: 3
        [1] (from line 17)
        2018-02-10 03:27:04 CET [30744]
        : [2-1] user= 2018-02-05 03:17:10 CET FATAL: terminating walreceiver due to timeout
        [2] (from line 19)
        ?
        ERROR: could not find /BACKUP/dev-replic/GEO_WAL_ARCH/00000002.history.gz
        [3] (from line 24)
        ?
        ERROR: could not find /BACKUP/dev-replic/GEO_WAL_ARCH/000000010000007E00000042.gz
Mon fichier de log de cette période contient :
        2018-02-10 03:09:27 CET [10365]: [121859-1] user=  2017-10-27 09:25:02 CEST LOG:  recovery restart point at 7E/3C000060
        2018-02-10 03:09:27 CET [10365]: [121860-1] user=  2017-10-27 09:25:02 CEST DETAIL:  last completed transaction was at log time 2018-02-10 03:00:01.319474+01
        2018-02-10 03:14:28 CET [10365]: [121861-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint starting: time
        2018-02-10 03:14:28 CET [10365]: [121862-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint complete: wrote 5 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.507 s, sync=0.001 s, total=0.514 s; sync files=3, longest=0.001 s, average=0.000 s; distance=32767 kB, estimate=32767 kB
        2018-02-10 03:14:28 CET [10365]: [121863-1] user=  2017-10-27 09:25:02 CEST LOG:  recovery restart point at 7E/3E000028
        2018-02-10 03:14:28 CET [10365]: [121864-1] user=  2017-10-27 09:25:02 CEST DETAIL:  last completed transaction was at log time 2018-02-10 03:10:01.899938+01
        2018-02-10 03:19:28 CET [10365]: [121865-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint starting: time
        2018-02-10 03:19:28 CET [10365]: [121866-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint complete: wrote 1 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 2 recycled; write=0.110 s, sync=0.001 s, total=0.119 s; sync files=1, longest=0.001 s, average=0.001 s; distance=16389 kB, estimate=31130 kB
        2018-02-10 03:19:28 CET [10365]: [121867-1] user=  2017-10-27 09:25:02 CEST LOG:  recovery restart point at 7E/3F001778
        2018-02-10 03:19:28 CET [10365]: [121868-1] user=  2017-10-27 09:25:02 CEST DETAIL:  last completed transaction was at log time 2018-02-10 03:15:01.896948+01
        2018-02-10 03:27:04 CET [30744]: [2-1] user=  2018-02-05 03:17:10 CET FATAL:  terminating walreceiver due to timeout
        2018-02-10 03:27:04 CET [10365]: [121869-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint starting: time
ERROR: could not find /BACKUP/dev-replic/GEO_WAL_ARCH/00000002.history.gz
        2018-02-10 03:30:20 CET [10365]: [121870-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint complete: wrote 3 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.066 s, sync=0.001 s, total=195.591 s; sync files=3, longest=0.001 s, average=0.000 s; distance=16387 kB, estimate=29655 kB
        2018-02-10 03:30:20 CET [10365]: [121871-1] user=  2017-10-27 09:25:02 CEST LOG:  recovery restart point at 7E/400023E8
        2018-02-10 03:30:20 CET [10365]: [121872-1] user=  2017-10-27 09:25:02 CEST DETAIL:  last completed transaction was at log time 2018-02-10 03:20:01.228392+01
        2018-02-10 03:30:20 CET [10355]: [40-1] user=  2017-10-27 09:25:02 CEST LOG:  restored log file "000000010000007E00000041" from archive
ERROR: could not find /BACKUP/dev-replic/GEO_WAL_ARCH/000000010000007E00000042.gz
        2018-02-10 03:30:20 CET [10355]: [41-1] user=  2017-10-27 09:25:02 CEST LOG:  unexpected pageaddr 7E/3C000000 in log segment 000000010000007E00000042, offset 0
        2018-02-10 03:30:21 CET [29405]: [1-1] user=  2018-02-10 03:30:20 CET LOG:  started streaming WAL from primary at 7E/42000000 on timeline 1
        2018-02-10 03:32:04 CET [10365]: [121873-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint starting: time
        2018-02-10 03:32:06 CET [10365]: [121874-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint complete: wrote 15 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=1.544 s, sync=0.011 s, total=1.562 s; sync files=8, longest=0.011 s, average=0.001 s; distance=16375 kB, estimate=28327 kB
        2018-02-10 03:32:06 CET [10365]: [121875-1] user=  2017-10-27 09:25:02 CEST LOG:  recovery restart point at 7E/41000060
        2018-02-10 03:32:06 CET [10365]: [121876-1] user=  2017-10-27 09:25:02 CEST DETAIL:  last completed transaction was at log time 2018-02-10 03:30:33.730929+01
        2018-02-10 03:37:04 CET [10365]: [121877-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint starting: time
        2018-02-10 03:37:04 CET [10365]: [121878-1] user=  2017-10-27 09:25:02 CEST LOG:  restartpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.004 s, sync=0.000 s, total=0.007 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16415 kB, estimate=27136 kB
Mon répertoire d'archivage ne contient pas de fichier : 00000002.history.gz
Par contre, j'ai bien les archives :
        -rw-rw---- 1 postgres postgres 30819 10 févr. 03:10 000000010000007E0000003E.gz
        -rw-rw---- 1 postgres postgres   193 10 févr. 03:10 000000010000007E0000003E.00000028.backup.gz
        -rw-rw---- 1 postgres postgres 32525 10 févr. 03:15 000000010000007E0000003F.gz
        -rw-rw---- 1 postgres postgres 33822 10 févr. 03:20 000000010000007E00000040.gz
        -rw-rw---- 1 postgres postgres 41948 10 févr. 03:30 000000010000007E00000041.gz
        -rw-rw---- 1 postgres postgres 40374 10 févr. 03:35 000000010000007E00000042.gz
        -rw-rw---- 1 postgres postgres 34182 10 févr. 03:40 000000010000007E00000043.gz
        -rw-rw---- 1 postgres postgres 30815 10 févr. 03:45 000000010000007E00000044.gz
        -rw-rw---- 1 postgres postgres 35616 10 févr. 03:50 000000010000007E00000045.gz
        -rw-rw---- 1 postgres postgres 30842 10 févr. 03:55 000000010000007E00000046.gz
Sur le maître, une bizarrerie, un log à 03h24 intercalé entre deux logs 03h30 :
        2018-02-10 03:26:59 CET [3287]: [3-1] user=postgres 10.71.4.20 2018-02-05 03:17:12 CET LOG:  terminating walsender process due to replication timeout
        2018-02-10 03:26:59 CET [3287]: [4-1] user=postgres 10.71.4.20 2018-02-05 03:17:12 CET LOG:  disconnection: session time: 120:09:47.504 user=postgres database= host=10.71.4.20 port=41062
        2018-02-10 03:30:17 CET [15500]: [52889-1] user=  2017-11-10 07:59:11 CET LOG:  checkpoint starting: time
        2018-02-10 03:30:18 CET [11584]: [1-1] user=[unknown] 127.0.0.1 2018-02-10 03:30:18 CET LOG:  connection received: host=127.0.0.1 port=60994
        2018-02-10 03:30:18 CET [11585]: [1-1] user=[unknown] 127.0.0.1 2018-02-10 03:30:18 CET LOG:  connection received: host=127.0.0.1 port=60996
        2018-02-10 03:30:18 CET [11584]: [2-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  connection authorized: user=postgres database=geo
        2018-02-10 03:30:18 CET [11585]: [2-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  connection authorized: user=postgres database=geo
        2018-02-10 03:24:19 CET [15503]: [3-1] user=  2017-11-10 07:59:11 CET LOG:  using stale statistics instead of current ones because stats collector is not responding
        2018-02-10 03:30:18 CET [11585]: [3-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  duration: 591.921 ms  statement: SELECT dba.inf_conn('geo');
        2018-02-10 03:30:18 CET [11585]: [4-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  disconnection: session time: 0:00:00.660 user=postgres database=geo host=127.0.0.1 port=60996
        2018-02-10 03:30:18 CET [11584]: [3-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  duration: 610.197 ms  statement: SELECT dba.inf_bgw();
        2018-02-10 03:30:18 CET [11584]: [4-1] user=postgres 127.0.0.1 2018-02-10 03:30:18 CET LOG:  disconnection: session time: 0:00:00.662 user=postgres database=geo host=127.0.0.1 port=60994
        2018-02-10 03:30:18 CET [15500]: [52890-1] user=  2017-11-10 07:59:11 CET LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.012 s, sync=0.000 s, total=0.833 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16375 kB, estimate=28327 kB
        2018-02-10 03:30:20 CET [11668]: [1-1] user=[unknown] 10.71.4.20 2018-02-10 03:30:20 CET LOG:  connection received: host=10.71.4.20 port=41542
        2018-02-10 03:30:21 CET [11668]: [2-1] user=postgres 10.71.4.20 2018-02-10 03:30:20 CET LOG:  replication connection authorized: user=postgres
Pour info : il n'y a pas d'activité sur ce cluster, sauf des tests en journée. La sauvegarde Pitrery s'exécute à 3h10 sur le maître (pas d'alerte).
Avez-vous une idée de ce qui s'est passé ?
D'avance merci.

#18 Re : Général » Sélection aléatoire dans liste de varchar » 08/02/2018 16:21:26

Rebonjour,
Désolé mais je n'arrive pas à appliquer.
J'ai essayé :
select (VALUES ('toto'),('titi'),('tata') ORDER BY random() LIMIT 1), ### from generate_series(timestamp '2018-01-01', '2018-02-08', '1 day');
Mais je ne sais pas comment remplacé mon ### par le jour.

#19 Re : Général » Sélection aléatoire dans liste de varchar » 08/02/2018 15:35:22

Bonjour,
Merci à vous pour la rapidité de la réponse.
Pour aller plus loin, j'ai une table avec cette structure :
CREATE TABLE test (username varchar(50) NOT NULL, jour date NOT NULL);
Je souhaite l'alimenter avec une ligne par jour, avec un generate_series(timestamp '2018-01-01', '2018-02-08', '1 day'), et en plus alimenter de façon aléatoire le champ username avec mes titi, toto, ...
Est-ce que l'on peut combiner le RANDOM et le GENERATE_SERIES ?

#20 Général » Sélection aléatoire dans liste de varchar » 08/02/2018 12:55:28

mortimer.pw
Réponses : 6

Bonjour,
Je travaille sur un moteur 9.3 sous Cent-OS 7.
Je voudrais alimenter une table en sélectionnant aléatoirement une valeur parmi une liste de varchar.
Est-ce possible ?
Un truc du genre : select random('toto','titi','tata', ....), qui me retourne une des valeurs.
D'avance merci.

#21 Re : pgAdmin4 » Invalid byte sequence for encoding "UTF8" » 18/01/2018 09:55:16

Guillaume,
Même problème avec différents serveurs Cent-OS 6-7, PostgreSQL 9.3-9.4-10.1. Même avec une base vide.
Même problème sur le poste d'un collègue.
Problème de config ? d'environnement ?
Bon, me voilà bien embêté :-(

#22 Re : pgAdmin4 » Invalid byte sequence for encoding "UTF8" » 18/01/2018 08:35:59

Bonjour Guillaume,
J'ai simplifié.
Création d'une BD :
CREATE DATABASE geo2 WITH OWNER = postgres TEMPLATE = template1 ENCODING = 'UTF8' CONNECTION LIMIT = -1;
Création d'une Table dans le schéma PUBLIC :
CREATE TABLE activite (id_cgu character varying(20) NOT NULL) WITH (OIDS=FALSE);
Je peux lire la définition de l'objet en cliquant sur l'onglet SQL.
Création de la Fonction Trigger :
CREATE OR REPLACE FUNCTION jf_recharge_activite() RETURNS trigger AS $BODY$ DECLARE BEGIN RETURN NULL; END;$BODY$ LANGUAGE plpgsql VOLATILE COST 100;
Création du Trigger :
CREATE TRIGGER jt_activite AFTER INSERT OR UPDATE OR DELETE ON activite FOR EACH ROW EXECUTE PROCEDURE jf_recharge_activite();
Toujours le même message d'erreur lors de la relecture de la définition de l'objet.

#23 Re : pgAdmin4 » Invalid byte sequence for encoding "UTF8" » 17/01/2018 09:18:13

Bonjour,

Je reviens vers vous car pas de réponse de PgAdmin-Support.

J'ai fait d'autres tests (je suis passé à PgAdmin 4 version 2.1, toujours sous windows 7 64 Bits).

Script de création de la base :
     CREATE DATABASE geo
    WITH
    OWNER = postgres
    ENCODING = 'UTF8'
    LC_COLLATE = 'fr_FR.UTF-8'
    LC_CTYPE = 'fr_FR.UTF-8'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1;

Script de création de table :
     CREATE TABLE geo.activite
(
  id_cgu character varying(20) NOT NULL,
  id_site character varying(20) NOT NULL,
  id_ligne character varying(4) NOT NULL,
  id_plan character varying(4) NOT NULL,
  id_fonction character varying(4) NOT NULL,
  id_operation character varying(5) NOT NULL,
  id_type_ptg numeric NOT NULL,
  id_type_act character varying(3) NOT NULL,
  tps_gam numeric(7,4) DEFAULT 0,
  tps_gam_test numeric(7,4) DEFAULT 0,
  id_type_coq character varying(3) NOT NULL,
  id_type_qte_act numeric NOT NULL DEFAULT 0,
  qte_igeo boolean NOT NULL DEFAULT false,
  id_alim_document numeric NOT NULL DEFAULT 0,
  id_type_cum_doc numeric NOT NULL DEFAULT 1,
  sum_quantite boolean NOT NULL DEFAULT true,
  id_methode_qt numeric NOT NULL DEFAULT 0,
  lfo_cgu character(12),
  date_fin date NOT NULL DEFAULT to_date('30000101'::text, 'YYYYMMDD'::text),
  CONSTRAINT pk_activite PRIMARY KEY (id_cgu, id_site, id_ligne, id_plan, id_fonction, id_operation, date_fin))
WITH (OIDS=FALSE);
ALTER TABLE geo.activite OWNER TO postgres;

Script de création d'une fonction trigger (volontairement vidée) :
     CREATE OR REPLACE FUNCTION geo.jf_recharge_activite() RETURNS trigger AS
$BODY$
DECLARE
BEGIN
    RETURN NULL;
END;
$BODY$ LANGUAGE plpgsql VOLATILE COST 100;
ALTER FUNCTION geo.jf_recharge_activite() OWNER TO postgres;

Script de création d'un Trigger sur la table :
     CREATE TRIGGER jt_activite AFTER INSERT OR UPDATE OR DELETE ON geo.activite FOR EACH ROW EXECUTE PROCEDURE geo.jf_recharge_activite();

Test avec une base en 10.1 directement sur mon P.C, pas de problème.

Test avec une base en 10.1 sous Cent OS 7, toujours le problème.
Lorsque j'essaye à nouveau de visualiser la définition de ma table (onglet SQL), le message d'erreur est reproduit.
C'est vraiment après ajout du trigger.

Pouvez-vous m'aider svp ?

#24 Re : pgAdmin4 » Invalid byte sequence for encoding "UTF8" » 08/12/2017 09:34:26

Bonjour Guillaume,
Visiblement nous avons l'erreur sur les tables qui ont des trigger.
Y-a-t'il un support pour PgAdmin IV ?
Il faut trouver une solution si PgAdmin III n'évolue plus.
Merci.

#25 Re : pgAdmin4 » Invalid byte sequence for encoding "UTF8" » 07/12/2017 09:11:31

Bonjour Guillaume,

Avec la même config "Serveur Encoding", "Client Encoding" et base de données ?
J'ai le même problème avec plusieurs serveurs.
Dans quelle direction faut-il creuser ?

Pied de page des forums

Propulsé par FluxBB