Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)

--5i06EVIDeN5/qxBX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Tom Lane ([email protected]) wrote:
> Stephen Frost <[email protected]> writes:
> > * Tom Lane ([email protected]) 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.
>=20
> > 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.
>=20
> 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.)

Right, makes sense.

> 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.

Yeah, I see how that's also an issue and agree that it makes sense to
report back what's been written and sent as a partial write, and not
report back everything we've "consumed" since we might not get called
again in that case.

Thanks!

Stephen

--5i06EVIDeN5/qxBX
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJeHihdAAoJEO1sijiDR2RV9LwQAImNF3eT3wrDatwxZoj90gSR
eMTpAvdOTJJNxMfiE7UB9za2H9TULms5U6YHlpDOpIugr5eoNoGkb8eSQoHim3Nu
dtYRZ2B+avoURHsgCjdFecpqTAI+njW2okRZ9qOHunYM9inYDYFa8dUlFSPHeT30
AmjQ3xayU9iIhNY9TB1KVJSkf0GMD6MmiiHwENdxX3zCaa+ex1+757F57gOIVs5Q
WVa/2lDuo/ixycRF40+ZW3U304vq3vSPhjtyDK39r5mXOMLZ1TY3YM/DAh06LYAu
rAgbbA6Xk4Niivq682I4NvthmY2bgYgMlm5HSE/S8k51Y+3iVaRn3/hPhei7jDXE
bgtW+WqzPIH5dxJtXavGq6UWcXGPp3wXirP7/K+8SZIri6NOTpkOfHSHuZlm51b9
Wy50ufBsYu2z+RhFkgrd7jTVunjJONSacNrLlHW3geJsKh1PxMoZ8TICaxW6Xs0F
derVeRgwnI+b+GSMvHfAHoo3Z6fZutzlc8hLwqakjcnOdkEzt5Cejwbf9tUr6C+Q
lRmctzZN9VcDxaJ1K4K2y+zF4Dl+5KQ6WBIc/7KPD5u1igel6FQx4vRgqvqSZsRc
R/xuZkegohZZZZ1rIZ5O+YRGhiSKltEWZAFuoeRHU6eYzbN4QDMrloeMqQ7cklwg
DbgIAtNUJrcXI/qxiBgs
=+Cm8
-----END PGP SIGNATURE-----

--5i06EVIDeN5/qxBX--