From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | markokr(at)gmail(dot)com |
Cc: | mmoncure(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com |
Subject: | Re: Speed dblink using alternate libpq tuple storage |
Date: | 2012-02-01 08:32:16 |
Message-ID: | 20120201.173216.21791705.horiguchi.kyotaro@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2012-02-01 09:09:56 | Re: Index-only scan performance regression |
Previous Message | Pavel Stehule | 2012-02-01 06:45:51 | Re: feature request - datum_compute_size and datum write_should be public |