Thread: Data corruption after an update set ...?
[Using postgresql-8.4.8-0squeeze1 under GNU-linux/debian]
Hi all!
I've just discovered that 456 records out of 1510 contained in a table
of my db bear the same content in two fields: the original data have
disappeared and I do not know how this occurred.
Luckily enough I'll be able to recover a large part of lost data but
would like to understand what happened: looking at .psql_history I can
see the command which might have caused the whole mess (see below)
although similar commands have been used in many other occasions without
doing any harm.
So the question are:
1. what caused the mess?
2. might depend on the processor (1300Mhz 10 years old)?
3. a HD failure?
I should be grateful for any hints.
Regards,
ennio
---------------------- .psql_history (partial)
_HiStOrY_V2_
..............
# update bibl_provv set titolo='Città scomparse. Tit.or.: «Versunken
# Städte. Eine Buch von Glanz und Untergang»', altre_notizie='Trad. di
# Enrico Massa. Prima edizione maggio 1971 nella collezione "I
# Garzanti"', n_pag_testo=363, car_tec_ed='br.fig.', largh_cm=11.0,
# alt_cm=17.8 where n_prog=10606;
..............
--
[Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?//
Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°)
Ricevo solo messaggi Content-Type: plain/text (no html o multipart). )=(
!!! --> e-mail a mio nome via OE (M$) sono false e infette <-- !!!
On Mon, Aug 22, 2011 at 3:36 PM, Ennio-Sr <nasr.laili@tin.it> wrote: > [Using postgresql-8.4.8-0squeeze1 under GNU-linux/debian] > > > Hi all! > > I've just discovered that 456 records out of 1510 contained in a table > of my db bear the same content in two fields: the original data have > disappeared and I do not know how this occurred. > > Luckily enough I'll be able to recover a large part of lost data but > would like to understand what happened: looking at .psql_history I can > see the command which might have caused the whole mess (see below) > although similar commands have been used in many other occasions without > doing any harm. > > So the question are: > 1. what caused the mess? > 2. might depend on the processor (1300Mhz 10 years old)? nope > 3. a HD failure? nope My money is on 'operator error'. Without having access to the logs and queries in question, that's what I have to assume. As always, frequent backups are your best defense. merlin
* Merlin Moncure <mmoncure@gmail.com> [220811, 16:27]: > On Mon, Aug 22, 2011 at 3:36 PM, Ennio-Sr <nasr.laili@tin.it> wrote: > > [Using postgresql-8.4.8-0squeeze1 under GNU-linux/debian] > > ... > > So the question are: > > 1. what caused the mess? > > 2. might depend on the processor (1300Mhz 10 years old)? > > nope > > > 3. a HD failure? > > nope > > > My money is on 'operator error'. Without having access to the logs > and queries in question, that's what I have to assume. As always, > frequent backups are your best defense. > > merlin Hi Merlin and thanks for your answer. I have perused throughout the logs but was unable to find anything strange. The sole remaining doubt is that the delimited text file used to copy data to the table was itself corrupted. AAMOF I've noticed in other occasion that sometimes, closing quickly a file which was being edited with vim (from console) causes the latest modification to fill up a whole line: the same might have occurred with my original file, although I found strange that four (non consecutive) out of 36 fields were involved. Moreover, supposing all the records involved were coming from that possibly corrupted file, the supposed vim corruption would have taken effect 'vertically' for the four fields concerned, which would be a completely new experience to me... Regards, ennio -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ] (°|°) Ricevo solo messaggi Content-Type: plain/text (no html o multipart). )=( !!! --> e-mail a mio nome via OE (M$) sono false e infette <-- !!!