Re: [HACKERS] 6.4.1 release
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] 6.4.1 release |
Дата | |
Msg-id | 199812121509.AAA00526@ext16.sra.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] 6.4.1 release ("Pascal André" <andre@via.ecp.fr>) |
Список | pgsql-hackers |
> > > > I think at least large object stuffs should be fixed(just a "select > > > > lo_import('/foo/bar')" easily kills backend) before 6.4.1. I've been > > > > looking into codes for sometime but have not found complete fixes yet. > > > > > > I thought we already had a large object fix in the two trees already? > > I thought I did. And in fact vanilla 6.4 (that include my patch; as I am not a > regular PostgreSQL developper, I did not set up SUP here) does not suffer the > specified bug (system is Linux 2.1.123/GNU libc 2; test-data is 121225 bytes long): Linux boxes does not seem to have any problem with large object. As far as I know, the bug appears on FreeBSD and Solaris/Sparc. I'm not sure about other platforms. > Tatsuo Ishii, could you try this surrounded with begin/end statements (and email me > > the result of course) ? The large object buffer problem I corrected was partly > related to freed buffers at the automatic commit (at the end of the query path in > the backend, outside transactions). The fix was to release buffers earlier. It > would be helpful in order to understand the exact problem. > > Thanks. Ok. Here are results. o FreeBSD: surrounding with begin/end prevents backend-crash. o Solaris: surrounding with begin/end does not help. I guess there may be another bug that is different from the one you mentioned. Solairs seems to be very "sensitive" to that kind of problem?:-) -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: