(resolution?) Re: [HACKERS] memory problem again
От | Daniel Kalchev |
---|---|
Тема | (resolution?) Re: [HACKERS] memory problem again |
Дата | |
Msg-id | 199912070825.KAA26222@dcave.digsys.bg обсуждение исходный текст |
Ответ на | Re: [HACKERS] memory problem again (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: (resolution?) Re: [HACKERS] memory problem again
|
Список | pgsql-hackers |
I found out how to resolve this problem, yet it does not explain why it happens anyway! I had postmaster started with this script: unlimit postmaster -D/usr/local/pgsql/data -B 256 -i -o "-e -S 8192" >> /usr/local/pgsql/errlog 2>&1 & Removing all the parameters to postmaster postmaster -D/usr/local/pgsql/data -i -o "-e" >> /usr/local/pgsql/errlog 2>&1 & made it work.... Perhaps some memory management problem? I guess the -S option is the culprit here, but this machine has 256 MB RAM and actually never swaps (yet). Hope this helps somehow. Daniel >>>Tom Lane said:> Daniel Kalchev <daniel@digsys.bg> writes:> > I have this problem with PostgreSQL 6.5.2:> > > logs=> selectdistinct confid > > logs-> from timelog199910> > logs-> where> > logs-> confid IS NOT NULL;> > pqReadData() -- backendclosed the channel unexpectedly.> > > The logged message in stderr (of postmaster) is > > FATAL 1: Memory exhaustedin AllocSetAlloc()> > Odd. I can't replicate this here. (I'm using 6.5.3, but I doubt that> matters.) There mustbe some factor involved that you haven't told us.> You don't have any triggers or rules on the table, do you?> > Hasanyone else seen anything like this?> > regards, tom lane
В списке pgsql-hackers по дате отправления: