Re: [HACKERS] v6.1 buffers and performance
| От | hotz@jpl.nasa.gov (Henry B. Hotz) |
|---|---|
| Тема | Re: [HACKERS] v6.1 buffers and performance |
| Дата | |
| Msg-id | 31d1bcd4c24d4d5b53c6416dac49bb44 обсуждение |
| Ответ на | [HACKERS] v6.1 buffers and performance ("Thomas G. Lockhart" <Thomas.Lockhart@jpl.nasa.gov>) |
| Список | pgsql-hackers |
At 12:21 AM 6/8/97, Igor wrote: >After it was done there were several array bounds read errors, one array >bounds write error (bad!!) and almost 300K of leaked memory...I am not >sure whether this memory stays allocated when the spawned backend >terminates, so I don't know whether it really affects anything..Array >errors are important though...Array bounds reads would read/return >garbage data, and array bounds writes could overwrite data... I agree that array bounds problems are *serious*, the write especially so. As to the fate of leaked memory: if the leak occurs in a child after the fork() then it doesn't matter at all after the child terminates. But can we guarantee that the amount of memory leaked is "small" even if the life of the child is "large"? The priorities seem obvious to me: 1) fix the array bounds problems. (If the fix is found after the 6.1 release then *immediately* release patches and/or version 6.1.1.) 2) Fix memory leaks in the parent PostMaster. (Make a 6.2 release ASAP.) 3) Fix memory leaks in the child processes, unless they can be determined to be unimportant for any conceivable transaction. I wouldn't normally go on at this length, except that I detect some ambivalence in the developer's posts on the subject. I hope that ambivalence is just an uncertainty in how to deal with the memory problems given the immaturity of the freeware tools, and not a desire to deny their seriousness. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------
В списке pgsql-hackers по дате отправления: