Subject: Re: Detecting test failures reported as warnings

From: Chapman Flack <[email-masked]>
Date: Wed, 17 Jun 2020 15:31:17 -0400

On 06/17/20 13:15, Kartik Ohri wrote:
> Out of the box, Powershell only supports MySQL server. ODBC drivers will be
> required to be built from source for use with Powershell which I think will
> not be worth the complexity.

Agreed.

> JDBC driver for Java or using python may be a
> viable option. I haven't had much success with the python version though.

I was looking at the various Python driver choices myself the other night
and it wasn't as promising as I thought. pg8000 was the pure-Python one
that I remembered, but can't access warnings (as far as I can tell).
py-postgresql looks quite promising and has message hooks, but even it
has native components, as do several others. I stopped before completing
an exhaustive survey.

There's a lot to like about a Java and JDBC approach. It shouldn't be hard
to get off the ground, JDBC has a nice standard API for finding out about
warnings (and reading through the pgJDBC code, I believe it is implemented,
though I haven't done a test yet).

Later on, as the prerequisites for migrating to TAP get accomplished,
that code could just be evolved to match.

> In any case, a very simple query suppressed INFO outputs SET
> client_min_messages TO WARNING. What should be the behaviour if warnings
> are found ? Should be marked as failed or passing.

My convention in the existing tests has been to use INFO to report
success, and WARNING to report failure. The idea would be to let the
test progress as far as it can, even complete if possible, but give an
overall not-passing result if there were warnings.

Regards,
-Chap

---

From: Kartik Ohri <[email-masked]>
Date: Thu, 18 Jun 2020 01:12:41 +0530

> that code could just be evolved to match.
As of now, setting client log level seems to work very well. Should I try
to work out this approach or go ahead?

---

From: Chapman Flack <[email-masked]>
Date: Wed, 17 Jun 2020 15:53:59 -0400

> to work out this approach or go ahead?

That sounds adequate for now. Especially if log_min_messages is still
at INFO (or could even go finer than that), and you can limit just the
client messages to warning, use that to detect success/failure, but put
the backend log into the build log.

Regards,
-Chap

---

From: Chapman Flack <[email-masked]>
Date: Wed, 8 Jul 2020 17:37:10 -0400

> that I remembered, but can't access warnings (as far as I can tell).

For the record, so no future reader of this thread is misinformed, I was
wrong about that. pg8000 does make notices/warnings available, using the
'notices' property of a pg8000 Connection. It is a deque that will hold
the most recent not-more-than-100 that were received. popleft() will
retrieve them in arrival order.

Each item is a dict that presents all of the fields of the PostgreSQL
notice, keyed by their single-character codes:

https://www.postgresql.org/docs/9.6/protocol-error-fields.html

So, not only was I mistaken to say "can't access", it in fact provides
better access than many other PG drivers.

Errors are a bit botched: those raise exceptions of course, and the
exception will have a tuple of values. Those are the values of all
the fields received from PostgreSQL, just as in the warning case, but
with all the keys thrown away, leaving you to guess which field is which.

-Chap