Kyotaro HORIGUCHI <horiguchi.kyot...@oss.ntt.co.jp> writes: >> What I'm currently thinking we should do is just use the old method >> for async queries, and only optimize the synchronous case.
> Ok, I agree with you except for performance issue. I give up to use > row processor for async query with dblink_is_busy called. Yeah, that seems like a reasonable idea. Given the lack of consensus around the suspension API, maybe the best way to get the underlying libpq patch to a committable state is to take it out --- that is, remove the "return zero" option for row processors. Since we don't have a test case for it in dblink, it's hard to escape the feeling that we may be expending a lot of effort for something that nobody really wants, and/or misdesigning it for lack of a concrete use case. Is anybody going to be really unhappy if that part of the patch gets left behind? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers