Vous n'êtes pas identifié(e).
Pages : 1
bonsoir,
je dois héberger sur mon serveur postgres plusieurs bases, chacune ayant un utilisateur dédié. Chaque utilisateur ne doit voir que sa base et pas les autres et ne peut administrer que sa base.
J'ai créé plusieurs bases, plusieurs rôles de connexion mais horreur, avec pgadminIII, chaque rôle de connexion voit toutes les bases. J'ai du louper quelque chose mais je ne vois pas.
Que faut-il faire pour étanchéifier complètement les environnements ?
merci de vos avis éclairés
résolu en supprimant le COLLATE pg_catalog."default"
étrange...
bonjour,
Sur la création d'un index,
CREATE INDEX "ix_dest_substr_detmdestinataires"
ON detm
USING btree
(substr(detmdestinataires, position('@' IN detmdestinataires)) COLLATE pg_catalog."default");
j'obtiens le message d'erreur suivant
ERREUR: la ligne index requiert 11704 octets, la taille maximum est 8191
Je n'ai rien trouvé à ce sujet en français et en cherchant en anglais sur "index row requires", je tombe sur des choses indiquant des tailles trop grandes.
Table « public.dest »
Colonne | Type | Modificateurs
-------------------+------+---------------
detmmailid | text | non NULL
detmdestinataires | text | non NULL
et select length(detmdestinataires) from dest order by 1 desc limit 1
me rend 658
Du coup, j ne comprends pas du totu ce message d'erreur.
Quelqu'un aurait-il une explication et surtout une solution ?
merci d'avance,
sur ce que j'ai déjà vu, le driver ODBC retransmet tel quel et n'a pas de connaissance sémantique sur la requête
En fait, je parlais de WAL non archivés. Je rencontre souvent des pb sur le fs des archives full qui du coup remplit par vase communiquant le fs pgdata (pg_xlog).
Vase communiquant n'est pas vraiment la bonne image, mais passons.
C'est à cause de pb comme un FS full que sont sortis d'excellents produits comme Nagios.
la RFC 1157 qui définit le SNMP existe depuis 1990 car le besoin existe depuis très longtemps
create table paris as SELECT nom, prenom, ville from la_table where ville='paris';
En France, il y a déjà Météo France avec une base de plusieurs Téra octets: http://www.postgresqlfr.org/temoignages:meteo_france
il y a aussi le moteur de recherche de Orange qui est voila.fr mais qui n'est pas dans le domaine du peta octets
Avec un ETL comme Talend, ça se résume à faire un glisser-déposer par table. On ne peut pas faire plus simple
pour ma part, sur de très grosses bases avec de volumineuxet nombreux index's, je préfère de très loin une sauvegarde logique que physique.
Quand à la restauration, on est clairement limité en version 8.4 par la vitesse d'accès disque lors de la création des index's (c'est d'ailleurs un des meilleurs benchmarks possibles pour les disques). Dans tous les cas, on va bien plus vite que la restauration d'un file system sans parler des problèmes causés par les tablespaces éparpillés sur plusieurs axes.
Cerise sur le gâteau, après restauration, on a une base très propre sans espace gaspillé :-)
c'est plutôt avec ton code php que tu as un soucis et surtout avec ce que tu mets dans this->recherche
les index's sont aussi une bonne indication des performances du système d'entrées/sorties puisque c'est de l'I/O pur. Typiquement, le RAID5 y montre toutes ses faiblesses ;-)
tu peux utiliser l'ETL Talend qio dispose d'un connecteur MaxDB
Pages : 1
