From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Hagerty <matthew(at)venux(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Finding corrupt data |
Date: | 1999-12-16 03:09:27 |
Message-ID: | 20394.945313767@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Matthew Hagerty <matthew(at)venux(dot)net> writes:
> Is it possible that corrupt data could cause a backend crash?
Absolutely. The scenario I've seen most is that the length word of a
variable-length field value (a "varlena" value in pghackers-speak)
contains garbage. The backend comes along and tries to allocate space
equal to the claimed field length in order to copy the value to
someplace, and the usual result is that the backend process exceeds
its allowed memory usage and is summarily killed by the kernel.
> If there was corrupt data in a table, how would one go about finding it?
The brute-force way is to do a SELECT * or COPY TO and see if the
backend survives ;-). If not, narrowing down which record is bad
is left as an exercise for the student...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-16 03:36:37 | Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock |
Previous Message | Bruce Momjian | 1999-12-16 01:43:11 | Re: [BUGS] uniqueness not always correct |