Re: Speed dblink using alternate libpq tuple storage
Kyotaro Horiguchi <horiguchi.kyotaro@oss.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>
To: markokr@gmail.com
Cc: mmoncure@gmail.com, pgsql-hackers@postgresql.org, greg@2ndquadrant.com
Date: 2012-02-01T08:32:16Z
Lists: 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