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

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> 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> 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>
>> pgsql-fr-generale(at)postgresql(dot)org)
>>
>
>
>