Re: Speed dblink using alternate libpq tuple storage

Поиск
Список
Период
Сортировка
От Shigeru Hanada
Тема Re: Speed dblink using alternate libpq tuple storage
Дата
Msg-id 4F30FC0A.6020900@gmail.com
обсуждение исходный текст
Ответ на 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>)
Список pgsql-hackers
(2012/02/02 23:30), Marko Kreen wrote:
> On Thu, Feb 02, 2012 at 04:51:37PM +0900, Kyotaro HORIGUCHI wrote:
>> Hello, This is new version of dblink.c
>>
>> - Memory is properly freed when realloc returns NULL in storeHandler().
>>
>> - The bug that free() in finishStoreInfo() will be fed with
>>    garbage pointer when malloc for sinfo->valbuflen fails is
>>    fixed.
> 
> Thanks, merged.  I also did some minor coding style cleanups.
> 
> Tagging it Ready For Committer.  I don't see any notable
> issues with the patch anymore.
> 
> There is some potential for experimenting with more aggressive
> optimizations on dblink side, but I'd like to get a nod from
> a committer for libpq changes first.

I tried to use this feature in pgsql_fdw patch, and found some small issues.

- Typos   - mes -> msg   - funcion -> function   - overritten -> overwritten   - costom -> custom
- What is the right (or recommended) way to prevent from throwing
exceptoin in row-processor callback function?  When author should use
PG_TRY block to catch exception in the callback function?
- It would be better to describe how to determine whether a column
result is NULL should be described clearly.  Perhaps result value is
NULL when PGrowValue.len is less than 0, right?

Regards,
-- 
Shigeru Hanada


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: incorrect handling of the timeout in pg_receivexlog
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: psql NUL record and field separator