Re: [HACKERS] backend dies suddenly after a lot of error messages
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] backend dies suddenly after a lot of error messages |
Дата | |
Msg-id | m10hbxY-000EBeC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] backend dies suddenly after a lot of error messages (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] backend dies suddenly after a lot of error messages
Re: [HACKERS] backend dies suddenly after a lot of error messages |
Список | pgsql-hackers |
> > Mirko Kaffka <mirko@interface-business.de> writes: > > We have problems with backend processes that close the channel because of > > palloc() failures. When an INSERT statement fails, the backend reports an > > error (e.g. `Cannot insert a duplicate key into a unique index') and > > allocates a few bytes more memory. The next SQL statement that fails > > causes the backend to allocate more memory again, etc. until we have no > > more virtual memory left. Is this a bug? > > Yeah, I'd say so --- all the memory used should get freed at transaction > end, but evidently it isn't happening. > > > We are using postgres 6.4.2 on FreeBSD 2.2.8. > > I still see it with 6.5-current sources. Will take a look. I remember to have taken some but haven't found all the places. I think there's still something in tcop where the querytree list is malloc()'d. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: