Re: Backends dying due to memory exhaustion--I'm stonkered - Mailing list pgsql-general

From Tom Lane
Subject Re: Backends dying due to memory exhaustion--I'm stonkered
Date
Msg-id 13714.980556190@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backends dying due to memory exhaustion--I'm stonkered  (Doug McNaught <doug@wireboard.com>)
List pgsql-general
Doug McNaught <doug@wireboard.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

pgsql-general by date:

Previous
From: Doug McNaught
Date:
Subject: Re: Backends dying due to memory exhaustion--I'm stonkered
Next
From: Doug McNaught
Date:
Subject: Re: Backends dying due to memory exhaustion--I'm stonkered