Re: [pgsql-fr-generale] Augmentation de taille incontrôlée d'une base

Re,

>> Release 7.4.7
>> Release date: 2005-01-31
>>
>> Soit plus de 3 ans, une *éternité* dans le monde PostgreSQL... (*)
>
> Oui, je sais, tu as raison. C'est difficile de pousser le client à faire
> des mises à jour quand tout fonctionne bien. Mais il est vrai que là, ça
> ne fonctionne plus bien...

Si tu avais besoin d'un argument massue, tu peux lui dire que sa version
est *connue* pour potentiellement *corrompre des données*.

Par exemple, juste dans la version 7.4.8, on a corrigé le bug suivant:

* Repair ancient race condition that allowed a transaction to be seen
as committed for some purposes (eg SELECT FOR UPDATE) slightly
sooner than for other purposes
This is an extremely serious bug since it could lead to apparent
data inconsistencies being briefly visible to applications.

Plus tard:

* Fix bug with row visibility logic in self-inserted rows (Tom)
Under rare circumstances a row inserted by the current command
could be seen as already valid, when it should not be. Repairs bug
created in 7.4.9 and 7.3.11 releases.

Encore plus tard:

* Prevent index corruption when a transaction inserts rows and then
aborts close to the end of a concurrent "VACUUM" on the same table
(Tom)

Donc, tu vois, te dire d'upgrader, ce n'est *vraiment pas* pour faire
mon vieux unixien barbu, mais vraiment parce que c'est dans ton intérêt.

> Effectivement, une mise à jour en restant en
> 7.4.x ne devrait pas causer de soucis (j'aimerais éviter d'avoir à
> recompiler aussi le middleware (PHP) au passage).

Oui, bah, reste en 7.4.x pour l'instant. Migrer à une 8.x avec x>=2 est
aussi une bonne idée, mais à prévoir un peu plus, (surtout pour la 8.3),
planifier, etc...

Installe donc la 7.4.19 et tiens-nous au courant, à savoir, si ça
corrige l'anomalie que tu constate ou pas. Le cas échéant, on regardera
ça en détails.

Bonne après-midi,

--
Jean-Paul Argudo
www.PostgreSQLFr.org
www.Dalibo.com