Re: Speed dblink using alternate libpq tuple storage

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
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-02 14:30:57
Message-ID: 20120202143057.GA12434@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
marko

Attachment Content-Type Size
libpq_rowproc_2012-02-02-2.diff text/x-diff 22.0 KB
libpq_rowproc_doc_2012-02-02-2.diff text/x-diff 6.0 KB
dblink_rowproc_2012-02-02-2.diff text/x-diff 13.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-02-02 14:39:29 Re: keywords in initdb are case-sensitive?
Previous Message Robert Haas 2012-02-02 14:30:48 Re: heap_tuple_needs_freeze false positive