Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


Attachment: libpq_rowproc_2012-02-02-2.diff
Description: text/x-diff (22.0 KB)
Attachment: libpq_rowproc_doc_2012-02-02-2.diff
Description: text/x-diff (6.0 KB)
Attachment: dblink_rowproc_2012-02-02-2.diff
Description: text/x-diff (13.7 KB)

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group