[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-hackers
Subject:    Re: [HACKERS] CommitFest 2009-09, two weeks on
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2009-09-30 20:52:48
Message-ID: 6237.1254343968 () sss ! pgh ! pa ! us
[Download RAW message or body]

Joe Conway <mail@joeconway.com> writes:
> 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?

Well, only the ones that want to implement cancel and don't have access
to the app's own signal handling functions.  (Which suggests that a
possible answer is to allow dblink to hook into the SIGINT catcher,
but frankly hooks in that location scare me ...)

I would argue that it's not necessarily a good idea at all: one of the
typical uses for dblink is to fake "autonomous transactions", and in
that application I don't think you *want* a cancel to propagate to the
other session.  If we did put this behavior into all dblink operations,
we'd need a way to turn it off.

Since dblink_cancel_query is already available, people who do want
cancels to propagate have the ability to do that.  I'm inclined to
think that this is complexity we don't need.

			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
[prev in list] [next in list] [prev in thread] [next in thread]