Re: Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Réparer pg_depend

Oui, mais on aurait des informations partielles ou erronées, mais une
erreur d'accès aux fichiers comme l'indique Guillaume dans un mail
croisé, non ?

Le 06/10/2015 14:19, Michel Payan a écrit :
> Effectivement, avec les bons droits, je pense qu'une mise à jour du
> dico est possible.
> Personnellement, je n'ai jamais essayé sur PG mais je sais que sous
> Oracle, MySQL, Sybase, MsSql, ... ça fonctionne et ça peut faire mal
> si l'on ne sait pas ce que l'on fait !
>
> Cdt
>
> Michel
>
>
>
> Le 6 octobre 2015 14:15, Thomas RAFFIN <traffin(at)sirap(dot)fr
> <mailto:traffin(at)sirap(dot)fr>> a écrit :
>
>
> Le 06/10/2015 14:05, Michel Payan a écrit :
>> La garantie de l'écriture disque est primordiale !
> Je comprends bien
>
>> La corruption n'est elle pas intervenue après un crash système ?
>>
>>
>
> Non, non, le système n'a pas planté du tout. Juste des erreurs
> dans les logs de postgreSQL lors des dumps réguliers, puis en nous
> connectant avec un client (pgAdmin par exemple) les mêmes erreurs.
>
> Les disques ne sont pas défectueux d'après les outils de Windows.
> Pour la RAM, je ne sais pas trop comment elle est allouée
> exactement entre les différentes machines.
>
> Sinon, est-il possible d'endommager les tables internes de PG via
> des requêtes SQL si on a les droits adéquats ?
>
>
>>
>> Le 6 octobre 2015 11:31, Thomas RAFFIN <traffin(at)sirap(dot)fr
>> <mailto:traffin(at)sirap(dot)fr>> a écrit :
>>
>>
>>
>> Le 06/10/2015 10:50, Cédric Villemain a écrit :
>>
>> vous devriez avoir un
>> #fsync=on
>> dans votre fichier de configuration.
>>
>> Avec Windows+machine virtuelle, je suppose que vous
>> utilisez des disques
>> déportés.
>> Pour garantir le bon fonctionnement des accès disques
>> sous windows vous
>> pouvez:
>> * définir wal_sync_method=fsync_writethrough
>> * ou conserver wal_sync_method = open_datasync (défaut
>> sous windows)
>> *ET* désactiver le cache en écriture globalement dans le
>> menu Windows
>> (cf stratégies dans les propriétés VMWare Wirtual Disk)
>>
>> Sans cela, les risques de corruption sont plus importants...
>>
>>
>> J'ai effectivement ça :
>> #fsync = on # turns forced synchronization on
>> or off
>> #wal_sync_method = fsync # the default is the first option
>> # supported by the operating system:
>> # open_datasync
>> # fdatasync (default on Linux)
>> # fsync
>> # fsync_writethrough
>> # open_sync
>>
>> Merci
>>
>> Pour le cache, je regarde. Mais ce qui est bizarre, c'est que
>> sur d'autres serveurs bien plus utilisés en volume de données
>> et connexions (et à priori dans des configs similaires) je
>> n'ai pas eu ce problème (mêmes versions OS et PG)...
>>
>> J'utilise aussi l'extension postgis, je ne sais pas si ça
>> peut avoir une influence.
>>
>> Sinon j'ai remonté une base vide et re-créé tous mes schémas,
>> tables, etc... exporté les données de chaque table de la base
>> corrompue, et ré-importé tout ça manuellement (COPY). Un peu
>> fastidieux, mais ça a l'air de fonctionner là... Je cherche
>> donc maintenant à éviter que ça ne se reproduise...
>>
>>
>>
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale
>> (pgsql-fr-generale(at)postgresql(dot)org
>> <mailto:pgsql-fr-generale(at)postgresql(dot)org>)
>>
>>
>
>