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  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] JOIN syntax. Examples?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Warning!!