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

Re: Speed dblink using alternate libpq tuple storage

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-01-31 02:59:31
Message-ID: 20120131.115931.266804142.horiguchi.kyotaro@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
This is fixed version of dblink.c for row processor.

> i'll re-send the properly fixed patch for dblink.c later.

- malloc error in initStoreInfo throws ERRCODE_OUT_OF_MEMORY. (new error)

- storeHandler() now returns FALSE on malloc failure. Garbage
  cleanup is done in dblink_fetch() or dblink_record_internal().
  The behavior that this dblink displays this error as 'unkown
  error/could not execute query' on the user session is as it did
  before.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment: dblink_use_rowproc_20120131.patch
Description: text/x-patch (11.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2012-01-31 03:07:52
Subject: Re: [GENERAL] Why extract( ... from timestamp ) is not immutable?
Previous:From: Tom LaneDate: 2012-01-31 01:41:17
Subject: Re: [GENERAL] Why extract( ... from timestamp ) is not immutable?

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