Re: Database possible corruption , unsolvable mystery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Hrm, you know that you -should- upgrade to at least the latest 7.4
> (7.4.13 I think is the most recent). looking from the 
> changelogs, there are a few bugs that you could be hitting;
> 
> 7.4.10
>     * Fix race condition in transaction log management There 
> was a narrow window in which an I/O operation could be 
> initiated for the wrong page, leading to an Assert failure or 
> data corruption.
> 
> 7.4.9
>     * Improve checking for partially-written WAL pages
>     * Fix error that allowed VACUUM to remove ctid chains too 
> soon, and add more checking in code that follows ctid links. 
> This fixes a long-standing problem that could cause crashes 
> in very rare circumstances.
> 
> 7.4.8
>     * Repair race condition between relation extension and 
> VACUUMThis could theoretically have caused loss of a page's 
> worth of freshly-inserted data, although the scenario seems 
> of very low probability. There are no known cases of it 
> having caused more than an Assert failure
> 
>     and these are only the ones that appear 'notably' in the 
> changelog. 
> In short, I -really- -would- -strongly- -advise- you 
> upgrading to 7.4.13. Personally, I would have made this my 
> first step, especially if your data is important.
> 
>     There is no need for a dump/reload between minor point releases. 
> Although there is a security fix in 7.4.8.
> 
>     Since the db is in a state of 'down' or repair, why not 
> do it now ? 
> two birds, one stone.

Thank you , this might be a good solution , but we have a bigger upgrade
comming for 8.1.x later on,
but considering that other things out of our hands might occur , we
might seriously look into it after fixing
the current problems :) [because we dont think that upgrading right now
will magicly fix the problem we are having.]
And on about 10 database [all 7.4.6] it is the first time this occur ,
and the symtom is really on one table, considering
a few terabytes of data sparsed accros a few db, we might have been
lucky yet but as of now its the first time 
we can see performance hit only on "delete".

But thanks alot for the hint. [even tho we never had some unexpected
data failure/crash] beside this out of control
human power failure that might have been the root of this [the database
is still dumping ...few gigs :)]

Thanks alot all for the help,and if we find the root cause we will give
feed back.

-elz

AVERTISSEMENT CONCERNANT LA CONFIDENTIALITE 

Le present message est a l'usage exclusif du ou des destinataires mentionnes ci-dessus. Son contenu est confidentiel et peut etre assujetti au secret professionnel. Si vous avez recu le present message par erreur, veuillez nous en aviser immediatement et le detruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.

CONFIDENTIALITY NOTICE

This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux