Horton

Thread

  1. Re: [HACKERS] Proposal for async support in libpq

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-04-17T20:47:45Z

    Bruce Momjian <maillist@candle.pha.pa.us> writes:
> You supply the indication to the backend, and I will see that the
> backend processes it properly.

You're on ;-)

Signaling the cancel request via OOB sounds reasonable, as long as
nothing else is using it and all the systems we care about support it.
(I see a couple of routines to support OOB data in
src/backend/libpq/pqcomm.c, but they don't seem to be called from
anywhere.  Vestiges of an old protocol, perhaps?)

I still need to understand better what the backend will send back
in response to a cancel request, especially if it's idle by the
time the request arrives.  Will that result in an asynchronous error
response of some sort?  Do I need to make said response visible to
the frontend application?  (Probably not ... it will have already
discovered that the query completed normally.)

How should cancellation interact with copy in/out?

These are mostly documentation issues, rather than stuff that directly
affects code in libpq, but we ought to nail it down.

			regards, tom lane

  2. Re: [HACKERS] Proposal for async support in libpq

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-04-17T21:01:17Z

    b> 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > You supply the indication to the backend, and I will see that the
> > backend processes it properly.
> 
> You're on ;-)
> 
> Signaling the cancel request via OOB sounds reasonable, as long as
> nothing else is using it and all the systems we care about support it.
> (I see a couple of routines to support OOB data in
> src/backend/libpq/pqcomm.c, but they don't seem to be called from
> anywhere.  Vestiges of an old protocol, perhaps?)

Probably.  There is a document on the libpq protocol somewhere.  I
assume you have that already.  It is pgsql/docs/programmer.ps.gz, around
page 118.

> 
> I still need to understand better what the backend will send back
> in response to a cancel request, especially if it's idle by the
> time the request arrives.  Will that result in an asynchronous error
> response of some sort?  Do I need to make said response visible to
> the frontend application?  (Probably not ... it will have already
> discovered that the query completed normally.)

Not sure the backend has to signal that it received the cancel request. 
Does it?  It could just return a NULL result, that I think is caused by
elog(ERROR) anyway, and we can put in some nice fancy text like 'query
aborted'.


> 
> How should cancellation interact with copy in/out?

Not sure on that one.  May not be possible or desirable, but we could
put something in commands/copy.c to check for cancel request.



-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

  3. Re: Proposal for async support in libpq

    Jan Vicherek <honza@ied.com> — 1998-04-21T04:59:55Z

    On Fri, 17 Apr 1998, Tom Lane wrote:

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > You supply the indication to the backend, and I will see that the
> > backend processes it properly.
> 
> You're on ;-)
> 
> Signaling the cancel request via OOB sounds reasonable, as long as
> nothing else is using it and all the systems we care about support it.

   SSH doesn't have OOB. You can't send an OOB via SSH encrypted channel. 

            Jan

 -- Gospel of Jesus is the saving power of God for all who believe --
Jan Vicherek ## To some, nothing is impossible. ##  www.ied.com/~honza
    >>>    Free Software Union President  ...  www.fslu.org    <<<
Interactive Electronic Design Inc.    -#-    PGP: finger honza@ied.com

  4. Re: Proposal for async support in libpq

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-04-21T16:34:40Z

    > 
> On Fri, 17 Apr 1998, Tom Lane wrote:
> 
> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > > You supply the indication to the backend, and I will see that the
> > > backend processes it properly.
> > 
> > You're on ;-)
> > 
> > Signaling the cancel request via OOB sounds reasonable, as long as
> > nothing else is using it and all the systems we care about support it.
> 
>    SSH doesn't have OOB. You can't send an OOB via SSH encrypted channel. 

I have trouble buying that.  SSH is just the socket filter.  Perhaps the
OOB data is not encrypted like the normal data?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

  5. Re: Proposal for async support in libpq

    Jan Vicherek <honza@ied.com> — 1998-04-21T19:27:04Z

     for one, it is not encrypted,
 for two, the receiving end doesn't listen for OOB (most likely because
sending side doesn't encrypt it)
  The sending side doesn't encrypt it because OOB concept (flushing unsent
data) is incompatible with simple *single-stream* encryption. flushing
breaks the decryption of the data -- it corrupts the stream, so it becomes
unencryptable.

      Jan

On Tue, 21 Apr 1998, Bruce Momjian wrote:

> > On Fri, 17 Apr 1998, Tom Lane wrote:
> > 
> > > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > > > You supply the indication to the backend, and I will see that the
> > > > backend processes it properly.
> > > 
> > > You're on ;-)
> > > 
> > > Signaling the cancel request via OOB sounds reasonable, as long as
> > > nothing else is using it and all the systems we care about support it.
> > 
> >    SSH doesn't have OOB. You can't send an OOB via SSH encrypted channel. 
> 
> I have trouble buying that.  SSH is just the socket filter.  Perhaps the
> OOB data is not encrypted like the normal data?


 -- Gospel of Jesus is the saving power of God for all who believe --
Jan Vicherek ## To some, nothing is impossible. ##  www.ied.com/~honza
    >>>    Free Software Union President  ...  www.fslu.org    <<<
Interactive Electronic Design Inc.    -#-    PGP: finger honza@ied.com