pg_dump fails, data integrity imperfect - Mailing list pgsql-general

At some point between april 13 and now a single row in my 'orders' table
became compromised and caused the failure of pg_dump upon which I had
been depending for a backup, sort of. I say sort of because I allowed
each days dump to overwrite the previous and as such cannot point to a
specific day and say "that's when it came unstuck". Upon deletion of the
afflicted row the pg_dump proceeded in an orderly manner.
Is there any obvious/common cause of corruption of (probably varchar)
data?
Is there any simple/automated detection scheme?

The database is on RedHat 6.1 linux box with a paltry 64 megs of ram to
entertain its celeron 333.  The dbase version is postgres 6.5.3 .
The whole kit is about to be upgraded to RedHat7.1/Postgres7.03 128Meg
533Mhz.


[postgres@midas pgsql]$ pg_dump bella>data/sunday.dump
FATAL 1:  Memory exhausted in AllocSetAlloc()
PQendcopy: resetting connection
SQL query to dump the contents of Table 'orders' did not execute
correctly.  After we read all the table contents from the backend,
PQendcopy() failed.  Explanation from backend: 'FATAL 1:  Memory
exhausted in AllocSetAlloc()
'.
The query was: 'COPY "orders" TO stdout;
'.
[postgres@midas pgsql]$


This is the last few lines that the dump output.  I have seperated
individual orders with a blank line for clarity

16997    1    Fri Dec 15 16:37:12 2000 PST    t    Cash    $2.94    $0.19    $0.00    1 Regular
SLC VEG $2.75<!> <!> <!>ISPEC<!><*>    COMPLETE    Pickup    f        716736777

16998    9802215    Fri Dec 15 16:43:21 2000 PST    f    Cash    $20.38    $1.33    $0.00    1
Medium HAW $12.25<!> <!> <!>0 0 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 1ISPEC<!><*>2 Small T.S. $3.00<!> <!> <!>ISPEC<!><*>4
Regular G.B. $3.80<!> <!> <!>ISPEC<!><*>    COMPLETE    Delivery    f        716736777

16999    9908055    Fri Dec 15 16:45:12 2000 PST    f    Cash    $17.92    $1.17    $0.00    1
Regular WH CHICK $9.75<!> <!> <!>0 0 0 1ISPEC<!><*>1 Regular L.M.S.
$7.00<!> <!> <!>ISPEC<!><*>    COMPLETE    Delivery    f        716736777

17000    9855620    Fri Dec 15 16:48:15 2000 PST    f    Cash    $20.60    $1.35    $0.00    1
Small BASIC $6.25<!> <!> <!>0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 0 0 0ISPEC<!><*>1 Small GOURMET $10.50<!> <!> <!>0 1
0 0 0 1 0 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1 0 0 0 0 0 0 1ISPEC<!><*>2
Regular Pop $2.50<!>2x R.B.<!> <!>0 0 0 0 0 0 2ISPEC<!><*>    COMPLETE
Delivery    f        716736777

17225    1    Sun Dec 17 01:45:29 2000 PST    t    Cash    $2.94    $0.19    $0.00    447 19688
19I!    8 19I!        f



Here's the 'wounded' ordernumber as queried from a previously dumped
version

bella=# select * from orders where ordnumber=17225;
 ordnumber | customernumber |       ordertime        | pickupdel |
paymethod | total | gstotal | discount |
items                     |  status  | pudelcharge | edits | wastecolumn
|   staff

-----------+----------------+------------------------+-----------+-----------+-------+---------+----------+-----------------------------------------------+----------+-------------+-------+-------------+-----------
     17225 |              1 | 2000-12-17 01:45:29-08 | t         |
Cash      | $2.94 |   $0.19 |    $0.00 | 1 Regular SLC VEG $2.75<!> <!>
<!>ISPEC<!><*> | COMPLETE | Pickup      | f     |             |
716736777
(1 row)





--

Glenn Wittrock

Linux: when you need to run like a greased weasel.