Re: [HACKERS] 6.4.1 release
От | Pascal André |
---|---|
Тема | Re: [HACKERS] 6.4.1 release |
Дата | |
Msg-id | 36722CE2.B3FCDB95@via.ecp.fr обсуждение исходный текст |
Ответ на | Re: [HACKERS] 6.4.1 release (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] 6.4.1 release
|
Список | pgsql-hackers |
Tatsuo Ishii wrote: > > > 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): andre=> select lo_import('/tmp/test-data'); lo_import --------- 18465 (1 row) andre=> select lo_unlink(18465); lo_unlink --------- 1 (1 row) > Following is a backend-crashing example. Any idea? [ snip : backend crash, identical to test case abose, but ... crashing ] That's quite similar to the previous problem. Did someone modify buffer handling recently? 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. -- Pascal ANDRE, Internet and Media Consulting andre@via.ecp.fr "Use the source, Luke. Be one with the Code." -- Linus Torvalds
В списке pgsql-hackers по дате отправления: