Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Général » créations de rôles utilisateurs "étanches" » 09/12/2016 21:59:06
- jmax
- Réponses : 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
#2 Re : Général » Erreur sur la création d'un index » 19/05/2014 16:24:55
résolu en supprimant le COLLATE pg_catalog."default"
étrange...
#3 Général » Erreur sur la création d'un index » 19/05/2014 14:27:44
- jmax
- Réponses : 1
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,
#4 Re : ODBC » Erreur avec la clause "AS" » 14/01/2011 09:05:18
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
#5 Re : Général » Comportement base de données PostgreSQL en cas de FS plein » 19/12/2009 09:30:03
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
#6 Re : Général » Trier et injecter dans une base. » 24/11/2009 17:15:04
create table paris as SELECT nom, prenom, ville from la_table where ville='paris';
#7 Re : Général » Bases de données avec très forte volumétrie » 17/09/2009 11:13:27
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
#8 Re : Migration » Migration vers SQL Server 2005 » 04/07/2009 07:18:53
Avec un ETL comme Talend, ça se résume à faire un glisser-déposer par table. On ne peut pas faire plus simple
#9 Re : Général » Sauvegardes d'une base de données PostgreSQL avec volumétrie > 1 To » 04/07/2009 07:17:29
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é :-)
#10 Re : Général » Problème de SELECT * avec un Full search » 26/05/2009 07:23:17
c'est plutôt avec ton code php que tu as un soucis et surtout avec ce que tu mets dans this->recherche
#11 Re : Général » Optimisation pour les COPY FROM » 07/03/2009 08:35:33
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 ;-)
#12 Re : Migration » Outils de migration vers PostgreSQL » 07/03/2009 08:31:49
tu peux utiliser l'ETL Talend qio dispose d'un connecteur MaxDB
Pages : 1