Vous n'êtes pas identifié(e).
On utilise généralement un "FULL VACCUM" suite à une grosse opération de maintenance.
Exemple : supprimer une grande partie des données. Le FULL va réécrire entièrement les données sur disque (data + index) et donc libérer de l'espace disque sur le serveur.
Bonjour,
PgModeler fait ça très bien aussi = https://pgmodeler.io/
Bonjour,
Jetez un oeil sur le "PREPARE" : https://docs.postgresql.fr/9.6/sql-prepare.html
C'est à l'application de gérer, donc : programmation
Bonjour,
Votre client (psql) est en 9.6.2 mais le serveur qui tourne est en 8.4.20.
Vous pouvez vérifier : cat /u02/app/pgdatabase/data/PG_VERSION
Bonjour,
Si ce que vous appelez un "utilisateur donné" est un utilisateur existant dans la base de données :
alter user user1 connection limit x;
alter user user2 connection limit y;Bonjour,
Now() va renvoyer la date et heure de début de transaction, il faut utiliser "select clock_timestamp()"
https://docs.postgresql.fr/9.6/functions-datetime.html
Les deux requêtes ne sont pas identiques :
après VALUES, dans la première, il y a 3 valeurs, alors que dans la deuxième, il y en a 2.Cela explique probablement la différence de résultat.
Merci pour ta réponse, mais c'est juste un mauvais copié / collé 
Donc j'ai toujours le problème 
Bonjour à tous,
J'ai une petite erreur de syntaxe avec une CTE + PREPARE + ON CONFLICT
Tables pour tester :
DROP TABLE IF EXISTS file;
DROP TABLE IF EXISTS action;
CREATE TABLE file (id_file SERIAL PRIMARY KEY,name TEXT);
CREATE UNIQUE INDEX unique_name ON file(name);
CREATE TABLE action(id_action SERIAL PRIMARY KEY, action_data JSON,id_file INTEGER);Le SQL qui ne passe pas :
-- NOT OK
PREPARE insert_file_action_err AS (
WITH file_data AS (
INSERT INTO file (name)
VALUES ($1)
ON CONFLICT("name") DO UPDATE SET id_file = file.id_file WHERE file.name = $1
RETURNING id_file
)
INSERT INTO action (id_file, action_data)
VALUES ((SELECT id_file FROM file_data), $2, $3) RETURNING id_action
);
-- ERROR: syntax error at or near "INSERT"
-- LINE 8: INSERT INTO action (id_file, action_data)Le SQL qui passe (le même mais sans les parenthèses après le AS du prépare) :
-- OK
PREPARE insert_file_action_ok AS
WITH file_data AS (
INSERT INTO file (name)
VALUES ($1)
ON CONFLICT("name") DO UPDATE SET id_file = file.id_file WHERE file.name = $1
RETURNING id_file
)
INSERT INTO action (id_file, action_data)
VALUES ((SELECT id_file FROM file_data), $2) RETURNING id_action
;Dans la doc, il n'y a pas de parenthèse après le AS du prépare :
PREPARE nom [ (type_données [, ...] ) ] AS instructionPourtant, les 2 cas simples suivants fonctionnent :
-- AVEC () :
PREPARE titi_ok AS (WITH toto AS (SELECT 1) SELECT * FROM toto);
-- SANS ()
PREPARE titi_ok2 AS WITH toto AS (SELECT 1) SELECT * FROM toto;C'est moi qui rate un truc ? C'est juste normal ?
Merci d'avance
Oui, vous devez avoir un problème dans votre requête car les "[" ne posent aucun problème dans un champs texte :
test=# select * from toto;
id | valeur
----+--------------------
1 | [a-zA-Z0-9_]{4,16}
(1 row)
test=# update toto set valeur = '[a-zA-Z0-9]{4,8}' where id = 1;
UPDATE 1
test=# select * from toto;
id | valeur
----+------------------
1 | [a-zA-Z0-9]{4,8}
(1 row)Pourquoi ne pas créer une contrainte sur vos doublons ? A partir de la 9.5, vous avez la possibilité de faire un INSERT ... ON CONFLICT DO NOTHING
Bonjour,
Les fichiers sont bien supprimés du FS
https://bucardo.org/wiki/Tail_n_mail#Debugging_options:
/usr/bin/perl /opt/tail_n_mail/tail_n_mail --dryrun --debug /opt/tail_n_mail/tnm.config.txtTu vas au moins voir si il récupère bien le log_line_prefix, c'est une première étape
J'ai déjà eu le problème, pour moi il faut supprimer le dernier espace dans votre .tailnmailrc pour avoir :
LOG_LINE_PREFIX = '%t [%p]: [%l-1] user=%u %h %s'Bonjour,
select pg_get_function_arguments(p.oid),p.proname, p.proowner, p.pronamespace from pg_proc p where p.proname='NOM_DE_LA_FONCTION';
oups : mal lu
Franchement vous partez dans une grosse galère ...
Perl est beaucoup utilisé par Debian (surtout une 6) et downgrader Perl me semble bien plus risqué que de dump/restore votre base sur un serveur PostgreSQL plus récent
la 7.2 date de 2002 ... Vous n'avez pas la possibilité d'upgrader votre serveur ?
Merci à toi pour la correction
Bonjour,
La recherche dans la documentation ne fonctionne plus : connexion impossible => http://docs.postgresql.fr/search.php
Merci !
Bonjour,
Quelle commande utilisez pour pour faire le backup ?
pour pouvoir ne restaurer qu'une table (ou un autre objet), il faut un backup au format "custom" => option -Fc
Si vous avez un backup qui se restaure avec psql, vous ne devez pas avoir le format custom, il ne vous reste plus qu'a editer le backup pour ne sortir que les infos que vous voulez. mais sur un fichier de 50go ...
bonjour,
Tout est dans le doc => http://docs.postgresql.fr/9.4/functions-bitstring.html
postgres=# select B'11111' # B'00001';
?column?
----------
11110
(1 row)c'est clair pour moi. et donc mon exemple de requête correspond à ton besoin.
Bonjour,
si je comprends bien, tu vas avoir des infos dans ta table des résolutions dns mais pas tout le temps ? et tu as besoin d'une double jointure.
si c'est ça, ill faut faire 2 left join =>
select log.*,src.hostname,dest.hostname from table_log log left join table_dns src on(src.ip = log.ip_src) left join table_dns dest on(dest.ip = log.ip_dest)bonjour,
moi je fais ça :
select 'alter table ' || schemaname || '.' || relname || ' owner to NEW_USER;' from pg_stat_user_tables;Ça génère le SQL, il ne reste plus qu'à l'executer