Oui c'est bien ce que j'ai remarqué, il me demande MON mot de passe. C'est bien cela (ajouter le -U postgres)
Mais le plus simple c'est encore d'utiliser pgAdminIII pour le faire...

Pour aller un peu plus loin, gleu a fait de la publicité pour un livre qui a l'air également de bien répondre à ton besoin :
Installer et débuter avec PostgreSQL
http://www.digitbooks.fr/catalogue/9782815001809.html

Je ne l'ai pas lu, mais il a l'air intéressant.  Et il aborde l'installation avec le "One Click installer".

Entretemps, pour info j'ai vu que le driver JDBC sait gérer LISTEN/NOTIFY.
lien vers la documentation

Sinon, pourquoi utiliser le cache de niveau 2 d'Hibernate? il me semble qu'on ne doit l'utiliser que pour des données rarement modifiées (données de référence, paramètres…), sinon on se contente du cache de premier niveau.

Si tu n'actives pas le cache de niveau 2 (ce qui est le plus fréquent), Hibernate évite justement de refaire un select, en se servant d'un numéro de version et en effectuant une requête de type :

update …
where cle = …
and version = …

et il vérifie l'incohérence en comptant le nombre de lignes modifiées (si zéro, c'est que la donnée a été modifiée entretemps)
Et s'il n'y a pas de numéro de version, il met tous les champs dans la clause Where…

A ta place, j'irai plutôt chercher du côté de Hibernate, sinon je crains que tu ne montes une usine à gaz en essayant de récupérer les Notify, puis en essayant d'en informer Hibernate, si c'est possible…
Ou alors je laisserai tomber Hibernate si le besoin n'est pas fort.

Il y a l'article de Marc :
ici :
et la documentation:
tutorial  et
la référence

%t STATEMENT:  alter session set nls_date_format='DD/MM/YYYY'

Ah ça, c'est de l'Oracle pur jus! Ton Hibernate pense avoir affaire à une base Oracle.
Tu devrais sans doute vérifier le paramétrage d'Hibernate.

COPY ?
http://docs.postgresqlfr.org/8.3/sql-copy.html

Ne serait-ce pas parce que tu as eu une erreur précédemment dans ta transaction?
Avec Oracle, il me semble que tu peux très bien ignorer une erreur et continuer ta transaction (ce qui est sale, soit dit en passant...). Avec PostgreSQL, non. Il faut donc que tu cherches l'erreur précédente pour connaître la cause de ton problème. Idéalement, il faudrait aussi que tu revoie la gestion des erreurs dans ta transaction...
(il est plus simple de regarder dans la log de PostgreSQL, j'ai déjà eu quelques soucis avec Hibernate, j'ai l'impression qu'il ne reporte pas toujours correctement les erreurs, en plus il est très bavard)
Pour le fait d'être en autocommit ou non, ça doit se régler dans Hibernate.

1) Le driver est là : http://jdbc.postgresql.org/
Et la documentation y est aussi.
Après c'est du classique : tu dois mettre le .jar dans le Build Path d'Eclipse (je suppose que tu fais le build de ton projet par Eclipse)
Pour le déploiement il doit être dans le CLASSPATH de ton application.

2)
Avec une SimpleDataSource (Il y a 2 implémentations fournies selon les besoins : http://jdbc.postgresql.org/documentation/80/ds-ds.html )

        org.postgresql.ds.PGSimpleDataSource ds = new org.postgresql.ds.PGSimpleDataSource();
        ds.setDatabaseName("basetest");
        ds.setUser("postgres");
        ds.setPassword("postgres");
        
        try {
            Connection con = ds.getConnection();
[...]

Avec le DriverManager :

            // chaine de connexion
        String url="jdbc:postgresql:basetest";
       
        Connection conn = null;
       
        Statement st = null;
        ResultSet rs = null;
       
        try {
       
            Class.forName("org.postgresql.Driver");
            conn = DriverManager.getConnection(url,"postgres","postgres");

Les différentes formes possibles d'URL sont décrites ici :
http://jdbc.postgresql.org/documentatio … nnect.html

3)
Que veux-tu dire par "se connecter à un schéma?". Une connexion JDBC se connecte à une base, pas à un schéma.

Tu peux exécuter les ordres SQL en précisant le schéma des objets, par exemple :

    Statement st = con.createStatement();
    st.execute("select * from schema1.matable");

Sinon, si tu veux éviter de préfixer le nom des objets par le schéma, va voir ce post :
http://forums.postgresql.fr/viewtopic.p … 1392#p1392

Flo

Pour syslog, c'est apparement dans /var/log.pgsql que les logs partent, vu sa configuration, non?
Il y a cette ligne dans le fichier syslog.conf :

local0.*                                                                  -/var/log/pgsql

Pourquoi utiliser pgfouine sur le fichier /PGSQL/PGTEST01/pg_log/postgresql-2009-04-15_102210.log dans ce cas?
/PGSQL/PGTEST01/pg_log/postgresql-2009-04-15_102210.log

Au fond, si j'ai bien compris, il y a 2 solutions :

Soit laisser log_destination à syslog, et lire le fichier écrit par syslog. Dans ce cas pour pgfouine il faut : fournir l'option "-logtype stderr" . Déjà, est-ce que le fichier existe? est-ce que syslog a été redémarré? Mais il faudrait trouver comment éviter de créer des fichiers inutiles?

Soit modifier postgresql.conf (remodifier log_destination pour qu'elle valle stderr).

(je ne peux pas tester ici, c'est par contre ce que je testerais si j'étais bil69)

NB : pour l'option l'option "-logtype stderr", ce ne serait pas lié au paramètre log_line_prefix = '%t [%p]: [%l-1] '   ?

Je n'ai pas de base de ce genre, mais tu peux facilement générer des données pour peupler une table avec generate_series :

Exemple pour générer 250 000 lignes:

insert into matable (id, name) select generate_series(1,250000) as truc, 'toto' || generate_series(1,250000) as machin;

test=# select * from matable;
   id   | data |    name   
--------+------+-----------
      1 |      | toto1     
      2 |      | toto2     
      3 |      | toto3     
      4 |      | toto4     
      5 |      | toto5     
      6 |      | toto6     
      7 |      | toto7     
(7 rows)

Pratique, non?

Ce que j'ai fait ensuite pour ma base de test, c'est écrire quelques procédures stockées pour peupler mes autres tables (il fallait dans mon cas que ce soit cohérent aussi fonctionnellement pour qu'on puisse utiliser l'application d'une manière réaliste). J'ai donc utilisé un mélange de valeurs "en dur", et de fonctions random() dans des boucles.

J'utilise (au boulot) postgresql 8.3.5 sur XP Pro SP2, sans problème.

Quelle version de postgresql as-tu essayé d'installer?
Avec quel moyen  : le "one clic installer", ou bien le msi?

Es-tu certain d'avoir récupéré l'intégralité du fichier? Il m'est arrivé une fois d'avoir des problèmes de ce genre, c'était dû à une corruption du fichier d'installation. As-tu vérifié la signature MD5 (si tu n'as pas pris la version "one click installer")? Ou vérifié la taille du .exe (si tu as pris le "one click installer"?

Lorsque tu fais un update, tu cherches à mettre à jour ta colonne avec une valeur donnée.
Par exemple :
update employes set salaire = 1000;
(tu mets tous les salaires de la table employes à 1000)
ou bien :
update employes set salaire = 1000 where nom = 'Dupont';
(tu mets à jour le salaire de tous les employés dont le nom est 'Dupont').

Dans le cas que tu nous donnes, la valeur est le résultat de la sous-requête : select champ2 from table2 a, table1 b where a.id = b.id
Or cette sous-requête ramène probablement plusieurs lignes, d'où l'erreur...

Si tu n'arrives pas à trouver comment résoudre le problème, il faudrait que tu donnes ta requête réelle (ou une requête similaire, mais parlante) et que tu nous explique ce que tu cherches à faire.
Cherches-tu à mettre à copier la valeur de table2.champ2 dans table1.champ1, en faisant le lien sur l'identifiant?