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

La garantie de l'écriture disque est primordiale !
La corruption n'est elle pas intervenue après un crash système ?

Le 6 octobre 2015 11:31, Thomas RAFFIN <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)
>