pg.ddx.io  pgsql-general@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Peter <pmc@citylink.dinoex.sub.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)
Date: Tue, 14 Jan 2020 15:22:00 -0500
Message-ID: <28741.1579033320@sss.pgh.pa.us> (raw)
In-Reply-To: <20200114201207.GA3195@tamriel.snowman.net>
References: <20200109181822.GA74698@gate.oper.dinoex.org>
	<7042.1578595681@sss.pgh.pa.us>
	<20200109205319.GA85142@gate.oper.dinoex.org>
	<15232.1578605504@sss.pgh.pa.us>
	<20200110022342.GA92515@gate.oper.dinoex.org>
	<12348.1578679149@sss.pgh.pa.us>
	<20200110210337.GA9580@gate.oper.dinoex.org>
	<26433.1578714710@sss.pgh.pa.us>
	<31477.1578756495@sss.pgh.pa.us>
	<20200114201207.GA3195@tamriel.snowman.net>

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> ... We must remember how much data we encrypted
>> and then discount that much of the caller's supplied data next time.
>> There are hints in the existing comments that somebody understood
>> this at one point, but the code isn't acting that way today.

> That's a case I hadn't considered and you're right- the algorithm
> certainly wouldn't work in such a case.  I don't recall specifically if
> the code had handled it better previously, or not, but I do recall there
> was something previously about being given a buffer and then having the
> API defined as "give me back the exact same buffer because I had to
> stop" and I recall finding that to ugly, but I get it now, seeing this
> issue.  I'd certainly be happier if there was a better alternative but I
> don't know that there really is.

Yeah.  The only bright spot is that there's no reason for the caller
to change its mind about what it wants to write, so that this restriction
doesn't really affect anything.  (The next call might potentially add
*more* data at the end, but that's fine.)

I realized when I got into it that my sketch above also considered only
part of the problem.  In the general case, we might've encrypted some data
from the current write request and successfully sent it, and then
encrypted some more data but been unable to (fully) send that packet.
In this situation, it's best to report that we wrote however much data
corresponds to the fully sent packet(s).  That way the caller can discard
that data from its buffer.  We can't report the data corresponding to the
in-progress packet as being written, though, or we have the
might-not-get-another-call problem.  Fortunately the API already has the
notion of a partial write, since the underlying socket calls do.

			regards, tom lane





view thread (22+ messages)  latest in thread

Message-ID: <28741.1579033320@sss.pgh.pa.us>
Permalink:  ../28741.1579033320@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/28741.1579033320@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-general@postgresql.org
  Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, pmc@citylink.dinoex.sub.org, pgsql-hackers@lists.postgresql.org
  Subject: Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)
  In-Reply-To: <28741.1579033320@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox