Re: libpq copy error handling busted

On Thu, Jun 4, 2020 at 1:53 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Thu, Jun 4, 2020 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Ah, it's better if I put the pqReadData call into *both* the paths
> > where 1f39a1c06 made pqSendSome give up.  The attached patch seems
> > to fix the issue for the "pgbench -i" scenario, with either fast-
> > or immediate-mode server stop.  I tried it with and without SSL too,
> > just to see.  Still, it's not clear to me whether this might worsen
> > any of the situations we discussed in the lead-up to 1f39a1c06 [1].
> > Thomas, are you in a position to redo any of that testing?

It seems to be behave correctly in that scenario.

Here's what I tested.  First, I put this into pgdata/postgresql.conf:

ssl=on
ssl_ca_file='root+client_ca.crt'
ssl_cert_file='server-cn-only.crt'
ssl_key_file='server-cn-only.key'
ssl_crl_file='root+client.crl'
ssl_min_protocol_version='TLSv1.2'
ssl_max_protocol_version='TLSv1.1'
ssl_min_protocol_version='TLSv1.2'
ssl_max_protocol_version=''

I copied the named files from src/test/ssl/ssl/ into pgdata, and I ran
chmod 600 on the .key file.

I put this into pgdata/pg_hba.conf at the top:

hostssl all all 127.0.0.1/32 cert clientcert=verify-full

I made a copy of src/test/ssl/ssl/client-revoked.key and ran chmod 600 on it.