On 27 Gen, 06:31, [EMAIL PROTECTED] (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 actually be 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
