Re: Speed dblink using alternate libpq tuple storage

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Speed dblink using alternate libpq tuple storage
Дата
Msg-id 20120201.173216.21791705.horiguchi.kyotaro@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Ответы Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Re: Speed dblink using alternate libpq tuple storage  (Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>)
Список pgsql-hackers
Hello,

> Another thing: if realloc() fails, the old pointer stays valid.
> So it needs to be assigned to temp variable first, before
> overwriting old pointer.
mmm. I've misunderstood of the realloc.. I'll fix there in the
next patch.

> And seems malloc() is preferable to palloc() to avoid
> exceptions inside row processor.  Although latter
> one could be made to work, it might be unnecessary
> complexity.  (store current pqresult into remoteConn?)

Hmm.. palloc may throw ERRCODE_OUT_OF_MEMORY so I must catch it
and return NULL. That seems there is no difference to using
malloc after all.. However, the inhibition of throwing exceptions
in RowProcessor is not based on any certain fact, so palloc here
may make sense if we can do that.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: feature request - datum_compute_size and datum write_should be public
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Index-only scan performance regression