Re: PostgreSQL Data Loss
От | desrocchi@gmail.com |
---|---|
Тема | Re: PostgreSQL Data Loss |
Дата | |
Msg-id | 1169910077.368699.205340@v33g2000cwv.googlegroups.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL Data Loss (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
On 27 Gen, 06:31, klep...@svana.org (Martijn van Oosterhout) wrote: > > To repeat: If you think this may have happened DO NOT run vacuum now.Actually, for XID wraparound a VACUUM may actuallybe the right thing. > I looked at this (with guidence from Tom) and we came to the conclusion > that XID wraparound will hide tuples older than 2 billion transaction, > but VACUUM will mark as frozen anything newer than 3 billion > transactions, so for 1 billion transactions you can actually get your > data back. > > Expect for things like uniqueness guarentees, but they're solvable. Hello,thank you all for the help. @Andrew Dunstan: this is the first time I'm having this kind of problem with PostgreSQL, I'm sorry I didn't provide all the needed information. Let me try to fill in something: - the postgresql version is 8.1.4-1 - as far as I know, nothing happened to the machine. I work near Milan, my customer is from something between Rome and Tuscany. It would be a long jurney to retrieve a PC that he surely won't give us. - The server logs... huh? Never heard of them... or better, never needed. Where can I find them? There is even a more foolish explanation to all of this, but my customer denied this happened: in my program it is possible to deactivate the auto-save function of the work done. Without this option the user has to click himself the button to store the data on the database... so it could even be that I'm trying to find data that has never even been saved. Anyway this teaches me that I have to put logs in my programs to trace every single time the users change settings. Bye, Daniele
В списке pgsql-hackers по дате отправления: