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

Le 6 octobre 2015 14:19, Michel Payan <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> 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)
>>>
>>
>>
>>
>

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com