Re: [HACKERS] v6.1 buffers and performance
| От | hotz@jpl.nasa.gov (Henry B. Hotz) |
|---|---|
| Тема | Re: [HACKERS] v6.1 buffers and performance |
| Дата | |
| Msg-id | c4033e33176fc9eed68a2e41f0b03d01 обсуждение |
| Ответ на | [HACKERS] v6.1 buffers and performance ("Thomas G. Lockhart" <Thomas.Lockhart@jpl.nasa.gov>) |
| Список | pgsql-hackers |
At 6:37 PM 6/8/97, Thomas G. Lockhart wrote: >Henry B. Hotz wrote: >> 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. > >Henry, my first reaction was probably pretty similar to yours but: > >1) postgres is already in _successful_ use >2) the latest release is more solid than the last We may not be so far apart. 1&2 are the reasons why I did not suggest holding off on the 6.1 release. >3) _all_ the code is inherited, and is something of an unknown quantity OTOH 3 is why I think it important to use tools like Purify to create known characteristics when possible. When they find serious problems we should provide fixes as soon as possible. >4) if the development team waited until the software were perfect, we >would have never seen it and probably never would. Well this is always true of hardware as well as software. In NASA we have a bit of a problem sending out a repair crew after a spacecraft is launched, but we do sometimes launch things anyway. Tom (I'm sure) and I could both tell stories, but it gets a bit off topic. >btw, Henry and I work at the place, although we've never met. It's >interesting seeing the somewhat different approach the postgres >developers must take for this to be successful. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu ------------------------------ End of hackers-digest V1 #380 *****************************
В списке pgsql-hackers по дате отправления: