Re: [GENERAL] Memory leak
От | The Hermit Hacker |
---|---|
Тема | Re: [GENERAL] Memory leak |
Дата | |
Msg-id | Pine.BSF.4.10.9908250854110.86612-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Memory leak (Michael <grim@argh.demon.co.uk>) |
Ответы |
Re: [GENERAL] Memory leak
|
Список | pgsql-general |
What version of PostgreSQL? The "backends dying problem", I thought, was fixed already... On Wed, 25 Aug 1999, Michael wrote: > Hi all > > I have just isolated a big problem in one of my applications and it turns out > to be a memory leak in postgresql on a VERY basic piece of functionality > > It just caused a backend to grow to 133 MB in 4 hours running, which is > obviously not good > > Simple piece of C code to demonstrate this: > > for (loopa=0;loopa < 100000;loopa++) > { > result=PQexec(dbase,"create table test_table ( " > "value int,wordnum int,refnum int,word text)"); > PQclear(result); > > result=PQexec(dbase,"drop table test_table"); > PQclear(result); > } > > And watch the memory risssssssse > > On an aside, any idea how long till there is a fix for the vacuum analyze > crash, as it is cripling me having that happen. > > Final question... Is there a really really good reason that when a backend > crashes, all the other backends die and close connection rather than simply > re-initialising their connections. If it just reinitialised transparently that > would make it a LOT easier than having to have an extra test to see if the > backend has mysteriously crashed after EVERY query! > > Thanx > > M Simms > > -- > #define z(x,y) for (x=0;x<y;x++){ > main(){long int i[3]={1214606444,1864390511,1919706122};int x,y; > z(x,3)z(y,4)putchar((i[x]>>((3-y)<<3))&(255)); > }}} > > > ************ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-general по дате отправления: