From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Doug McNaught <doug(at)wireboard(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Backends dying due to memory exhaustion--I'm stonkered |
Date: | 2001-01-27 00:43:10 |
Message-ID: | 13714.980556190@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Doug McNaught <doug(at)wireboard(dot)com> writes:
> Hmm, very interesting. Does VARCHAR count as a variable-size column?
Yes. (So does char(n) btw...)
> One funny thing is that the nightly VACUUM doesn't always fail--the
> system will run smoothly for one to three days on average before a
> crash.
That does seem to contradict the corrupt-data theory. Do you run a
VACUUM ANALYZE or just a plain VACUUM? If there were a persisting
corrupted tuple, I'd expect VACUUM ANALYZE to crash always, VACUUM
never (VACUUM doesn't inquire into the actual contents of tuples).
> That's a thought, and I will try it. I'm currently (as of yesterday's
> crash) running with -d 2 and output sent to a logfile. Is this
> debuglevel high enough to tell me which table contains the bad tuple,
> if that's indeed the problem?
That would tell you what query is running. It's not enough to tell you
where VACUUM is unless you do VACUUM VERBOSE.
> If I can't nail it down that way, how hard would it be to write a C
> program to scan all the tuples in a database looking for bogus size
> fields?
Fairly hard. I'd suggest instead that you just do
psql -c "copy FOO to stdout" dbname >/dev/null
and try that on each table in turn to see if you get any crashes...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2001-01-27 00:50:28 | Re: Backends dying due to memory exhaustion--I'm stonkered |
Previous Message | Doug McNaught | 2001-01-27 00:35:09 | Re: Backends dying due to memory exhaustion--I'm stonkered |