(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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Kalchev
Дата:
Сообщение: Re: [HACKERS] memory problem again
Следующее
От: Peter Mount
Дата:
Сообщение: RE: [HACKERS] When is 7.0 going Beta?