Est-ce que vous pouvez poster l'extrait du fichier de logs  ?

Le problème peut avoir des multiples origines....

Le plus simple et le plus serait de récupérer une sauvegarde récente, faire un initdb et repartir de cette sauvegarde. Mais j'imagine que si vous en êtes là c'est que ce n'est pas possible pour vous.

La commande pg_resetxlog peut aider mais c'est dangeureux :

1- Faire une copie de votre répertoire PGDATA
2- Tenter un pg_resetxlog
3- Essayer de relancer le serveur

Si le serveur redémarre, votre base sera potentiellement inconsistante. Vous devrez ensuite :

4- Faire un dump des données
5- Lancer initdb
6- Recharger les données

Si le serveur ne redémarre pas, repartez de votre copie (étape 1)

Quoiqu'il en soit prenez le temps de lire la doc de pg_resetxlog pour vérifier que la commande correspond à votre situation

..... Et soyez prêts à en assumer les conséquences

http://docs.postgresqlfr.org/8.2/app-pgresetxlog.html

Bon courage

1/ Le terme "user" est un nom réservé du langage SQL.  Utilisez un autre nom pour désigner votre utilisateur.

2/ Ne mettez pas de majuscules dans les noms d'objet

L'exemple ci-dessous fonctionne :

CREATE ROLE plop;
CREATE SCHEMA wiz;
ALTER SCHEMA wiz OWNER TO plop;
SET ROLE plop;
SHOW ROLE;
CREATE TABLE  wiz.boum(id SERIAL);

Là ça concerne Windows.... Consultez la doc de windows, ça doit être expliqué quelque part.

A vue de nez je dirai que ça se fait en 4 étapes :

1- Aller sur le Panneau de config
2- Afficher les Comptes utilisateurs
3- sélectionner le compte "postgres"
4- supprimer

a/ La version 2.x est de plus en plus stable, même si la version 1.x reste la plus couramment utilisée.

b/ Les limitations de la 2.x sont les mêmes que pour la 1.x. Il est important de comprendre que tous les changements de schémas de la base devront être fait via des scripts Slonik. Slony implique une surcharge de travail et de maintenance qui ne doit pas être négligée.

c1/ Vérifier que vous n'utilisez pas de blob ou de champs binaires
c2/ Vérifier que  le schéma de la base est figé

d/ Sans plus d'information, il est difficile de vous orienter entre les deux solutions...

Au final, réfléchissez bien avant de vous tourner vers Slony c'est un logiciel très puissant qui demande beaucoup d'attention et ajoute une couche de complexité à votre infrastructure.

Si votre but est simplement d'avoir un serveur de secours en cas de crash du serveur principal, alors la mise en plase du Warm Standby est beaucoup plus simple et largement suffisante. Voir l'article si dessous pour un tutoriel complet :

Réplication War Standby :
http://www.dalibo.org/hs44_la_replicati … ansactions

Et pour info, la doc de Slony est disponible en français là : http://www.slony.fr/

1/ PostgreSQL peut supporter 60 partitions sans problème.

2/ La taille maximale du table est 32 TB . Si vous atteignez cette limite, c'est qu'il y a un problème dans votre modèle de données.

Bonjour,

La première chose à dire c'est que la version 7.4 est périmée. Vous devez migrer vers une version plus récente le plus vite possible.

Avez-vous les extraits des journaux de log correspondants à la période ou les bases disparaissent ?

Les liens ci-dessous décrivent une installation sous Linux

http://www.dalibo.org/installation_du_log_shipping
http://www.dalibo.org/hs44_la_replicati … ansactions

La seule différence se situe au niveau de la configuration archive_command. Tu peux utiliser copy en remplacement de scp

Je viens de modifier votre message pour supprimer le nom d'utilisateur et son mot de passe.

Publier les codes d'accès d'une base sur un forum web n'est pas une bonne idée :-)

Quelques vérifications :

a/ Vérifier que le socket se trouvent bien à l'emplacement que vous annoncer : /var/run/postgresql

b/ les lignes qui matchent sur localhost ne sont pas cohérente entre IPv4 et IPv6

      host    all         all         127.0.0.1/32          trust
      host    all         all         ::1/128               ident

c/ essayez d'utiliser 127.0.0.1 plutot que localhost

d/ Beaucoup de ligne sont redondantes dans votre fichier pg_hba.conf. Par exemple :

  host     all    robert   monip_adress/32          md5
  hostssl  all    robert    monip_adress/32          md5

le tag host inclue hostssl + hostnossl donc la seconde ligne est parfaitement inutile

Même chose pour

host    all         all         127.0.0.1/32          trust
host    all         all         127.0.0.1/32          md5

Le fichier pg_hba.conf est déjà assez complexe à configurer ! Ne vous compliquez pas la tache avec des lignes redondantes.

Essayez de mettre en commentaire les lignes inutiles. Moins il y aura de lignes actives plus le débuggage sera simple.

damned ! Marc a été plus rapide moi

voila ma version :

SELECT id,l 
FROM ( 
     SELECT id, title, 
                 length(title) AS l, 
                 min(length(title)) OVER (PARTITION BY md5) AS m 
     FROM content
     ) AS s 
WHERE m=l;

Ce qui donne :

postgres=# select * from content;
 id |   title   | md5 
----+-----------+-----
  1 | 1         | z
  2 | 22        | z
  3 | 999999999 | z
  4 | 666666    | y
  5 | 4444      | y
  8 | 8         | z

postgres=# SELECT id,title,m FROM ( SELECT id, title, length(title) as l, min(length(title)) OVER (PARTITION BY md5) as m FROM content) AS s where m=l;
 id | title | m 
----+-------+---
  5 | 4444  | 4
  1 | 1     | 1
  8 | 8     | 1
(3 lignes)

C'est à dire ?

Aucun des raise notice ne s'affiche ? Que disent les logs ?