Re: [PATCH] Fix Ctrl-C related issues in psql (not for 8.1)

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCH] Fix Ctrl-C related issues in psql (not for 8.1)
Date: 2006-06-14 20:32:41
Message-ID: 20060614203241.GI4748@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Wed, Jun 14, 2006 at 12:55:10PM -0400, Tom Lane wrote:
> I'm not totally satisfied with the large-object fix yet; sometimes you
> have to hit control-C quite a few times before you manage to abort a
> long-running \lo_import or \lo_export. This is because the QueryCancel
> request does nothing if it arrives at the backend between lowrite() or
> loread() function calls. The only obvious fix is to duplicate libpq's
> lo_import() and lo_export() functions into psql so that we can add
> cancel_pressed checks into their loops (obviously libpq itself can't
> check that). Which is kinda yucky. Any thoughts?

Well, the obvious thing I can think of is that PQcancel also set a flag
in the PGconn structure which long-running functions (like lo_import)
in libpq could check.

If lo_import and lo_export are the only two functions that check that
flag, only they need to reset it. Although it probably wouldn't hurt to
reset it each query. I wouldn't worry about using it anywhere else in
libpq, since people seem to be ok with the current semantics.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-06-14 20:44:38 Re: COPY view
Previous Message Tom Lane 2006-06-14 20:14:09 Re: SQL/XML publishing function experimental patch II