Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id 20120405.092858.42412394.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > I'm afraid not re-initializing materialize_needed for the next query
> > in the latest dblink patch.

I've found no need to worry about the re-initializing issue.

> I've committed a revised version of the previous patch.

Thank you for that. 

> I'm not sure that the case of dblink_is_busy not being used is
> interesting enough to justify contorting the logic, and I'm
> worried about introducing corner case bugs for that.

I'm afraid of indefinite state by mixing sync and async queries
or API call sequence for async query out of my expectations
(which is rather narrow).

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch: improve SLRU replacement algorithm
Next
From: Robert Haas
Date:
Subject: Re: invalid search_path complaints