Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Joe Conway <mail@joeconway.com> writes:
>>> Robert Haas wrote:
>>>> - There is one dblink pach left over from last CommitFest. Joe Conway
>>>> was going to review it the weekend of July 18th-19th, but that didn't
>>>> end up happening and so that patch is still waiting. We might be able
>>>> to find someone else to review it, but I'm not sure whether that will
>>>> help unless there is a committer other than Joe with bandwidth to do
>>>> the final review and commit.
>>> I will get to it before the end of this commitfest, but I have to admit
>>> I'm not all that excited about this patch in the first place. I don't
>>> know that I agree with the need.
>> Well, you're the dblink expert. If you think it should be rejected
>> I doubt many of us will argue with you.
>
> Yep. CommitFest doesn't mean "commit it"; it means "decide whether to
> commit it". Things being rejected or returned with feedback for
> further improvement is fine; we're just trying to avoid long periods
> with no response at all.
The issue is not so much technical as it is philosophical.
The patch basically forces all use of libpq by dblink to be asynchronous
(internally) so that a cancel can be sensed and passed down to the
remote side and everything cleaned up. Possibly the right thing to do,
but dblink already allows the use of async queries, and the current
synchronous method uses standard libpq calls. If all of this is really
necessary, doesn't every libpq client have the same issue? If so why
have the synchronous libpq functions at all?
So while I can vet the patch technically, and spend more time
understanding the use case, and maybe explaining it better, I think
other people should weigh in on the change as it is significant and
points to other potential issues.
Joe