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

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>)
>
>