Re: Backends dying due to memory exhaustion--I'm stonkered
От | Tom Lane |
---|---|
Тема | Re: Backends dying due to memory exhaustion--I'm stonkered |
Дата | |
Msg-id | 13714.980556190@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Backends dying due to memory exhaustion--I'm stonkered (Doug McNaught <doug@wireboard.com>) |
Список | 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 по дате отправления: