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

Merci

Le 06/10/2015 14:37, Guillaume Lelarge a écrit :
> Le 6 octobre 2015 14:19, Michel Payan <michel(dot)payan(at)gmail(dot)com
> <mailto:michel(dot)payan(at)gmail(dot)com>> 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 !
>
>
> L'erreur indiquée n'est pas une erreur qu'il est possible de
> déclencher par des requêtes SQL. Plus exactement, il est possible de
> faire du mal en mettant à jour les catalogues systèmes (il faut être
> superutilisateur pour cela), mais cela ne causera pas ce type d'erreur
> (qui vient directement de la lecture sur disque).
>
> 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>)
>>
>>
>
>
>
>
>
> --
> Guillaume.
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com