Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Shigeru Hanada
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id 4F30FC0A.6020900@gmail.com
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Responses Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: incorrect handling of the timeout in pg_receivexlog
Next
From: Peter Eisentraut
Date:
Subject: Re: psql NUL record and field separator